Yeah the "was never meant to replace" here sounds exactly like the placation we got with wasm - "it's not meant to replace JavaScript" (it totally is).
The word meant is doing a lot of heavy lifting here. Meant - by who? The technology itself doesn’t want anything.
Do some people want to use wasm instead of JavaScript for websites? Yes. Will JS ever be removed from web browsers? Probably not, no. Wasm isn’t a grand design with a destiny it’s “meant to” reach. It’s actually just some code written by a bunch of people trying to solve a bunch of disparate problems. How well wasm solves any particular problem depends on the desires and skills of the people in the room, pushing the technology forward.
It’s kind of like that for everything. Rust was never meant to be a high performance systems language by its original creator. But the people in the room pushed it in that direction. Fuscia could replace Linux in Android. I’m sure some people want that to happen, and some people don’t. There’s no manifest destiny. What actually happens depends on a lot of arguing in meeting rooms somewhere. How that turns out is anyone’s guess!
> Meant - by who? The technology itself doesn’t want anything.
The people who created the project and who are writing the code, obviously. This is clear from the context; you don't need to nitpick stuff like this.
> Wasm isn’t a grand design with a destiny it’s “meant to” reach.
Yes it is. The destiny is being able to create dynamic websites with languages other than Javascript. The first step was Asm.js which allowed compiling other languages to Javascript. Then we got WASM which compiles them to a binary format instead. But you still need some Javascript glue to interact with the DOM APIs. And now there are extensions in progress that will remove that requirement (GC, reference types etc).
> Rust was never meant to be a high performance systems language by its original creator.
Yeah citation needed. The very first compiler release already described it as "a strongly-typed systems programming language with a focus on memory safety and concurrency."
>> Meant - by who? The technology itself doesn’t want anything.
> The people who created the project and who are writing the code, obviously. This is clear from the context; you don't need to nitpick stuff like this.
This isn't a nitpick, it's an important point.
Even on a small project, but especially at a huge company, there will be different ambitions and motivations for doing things.
ie, one person wants Fuchsia to eventually take over all of Google's OSes, another wants a secure IoT OS, another just wants a cool research project to pursue ideas about OSes they've had since grad school, etc...
Ah, but you’ve moved the goalposts! The original claim was that wasm would replace JavaScript. Now you’re just talking about wasm being another option from JavaScript for web development.
This distinction really seems to matter to some people. I suppose there’s something tribal about it. Is rust here to destroy C++? Rust gets a lot of irrational hate in the C++ community, and I think this perception is the reason. Is Fuscia here to destroy Android? To some, this will be a very emotionally important question.
> Yeah citation needed. The very first compiler release already described it as "a strongly-typed systems programming language (…)”
> Performance: A lot of people in the Rust community think "zero cost abstraction" is a core promise of the language. I would never have pitched this and still, personally, don't think it's good.
There might have been a time when Fuchsia included some UI/UX elements to it, but that was long ago. For the last half decade there has been basically no overlap in what Android offers vs what fuchsia offers. They don't really compete and there is no one who wants fuchsia to supercede Android. The only people who want this don't understand what fuchsia is and simply want some drama. Comparing it to rust vs c++ is not really a good comparison as those languages overlap a great deal in terms of use cases and features.
Is it? I don’t think those statements are incompatible in either example. In both scenarios we are looking at very meaningful leaps forward in terms of the underlying architecture and what that enables that simply aren’t possible within the boundaries of what is out there currently. I don’t think that’s the same thing as “meant to replace” at all though.
As we always joke in Germany nowadays when clearly there is intention even if public denied, we remind ourselves there was never an intention to build a wall, until there was actually one standing there.
