One part of Quantum, which does not have anything to do with Rust, is to figure out how we can spend less time running unimportant JS (like maybe in a background tab), which will hopefully reduce CPU usage.
Which, also posted on front page of HN recently, a user's medium blog on compiling Rust to WASM. https://medium.com/@chicoxyzzy/compiling-rust-to-webassembly...
Sites using JS to run simple scripts or to fire api calls/etc. will continue to use JS, no reason to use WASM.
Also, I believe WASM is truly compiled code and not JIT ran? I may be wrong...but pretty sure that was the whole point of creating it. Native app performance in the browser... that will take a big bite out of the app stores that take a good cut of revenue and control what can and can not be in the store.
And sure, WASM can also have memory safety problems, especially with C/C++ being the primary languages to target WASM from. But that's also where Rust would shine, making it much more safe when compiled to WASM.
The existing WASM implementations do a mixture of JITing code at load-time and JITing code at first-call, depending on the size of the WASM blob, AFAIK. The gain performance wise over asm.js is primarily in parse-time, as far as I'm aware.
WASM VM itself is perfectly possible to be memory safe: WASM code cannot read outside of the memory allocated to it (and malloc/free are implemented on top of that memory allocated to the VM, hence there's memory safety at the VM level).
The big problems come when you need to guarantee your JIT code doesn't violate memory safety, and that's something Rust's type system cannot (currently) solve. You need guarantees that the generated code will never have any memory access errors, and will never race for memory reads/writes, because it's running with the privilege of the VM, not the limited powers of the WASM code running within it.
[0] Note: parallelism is not the same as concurrency.
Browsers implement web workers and a "system call" which lets users initialize them through JS. A different implementation/deployment environment like Node does not have web workers. Through native modules, Node can have parallelism, but this is not a part of the language and Node isn't subject to implement web workers to be considered "running JavaScript". However, regardless of this JavaScript continues to have concurrency without parallelism. It would have been more accurate for my last message to have said: "I consider the lack of parallelism in JavaScript a feature given that it continues to have concurrency by default".
Similarly, I'd argue that C does not have parallelism (just system calls ...), but C doesn't even have concurrency. As such I do not consider the lack of parallelism a feature of C.
But the developers developing bloated code are most visible in the last shiny thing, which happens to be web and JavaScript. Before that it was mobile apps.
The combination of language and library provide affordances that make some idioms easier to represent, and others harder. This influences the design of code written in the language. Clumsy idioms generally don't get far, even if they would be more performant or provide some other benefits, like promote easier concurrency. And sometimes there's a tension: e.g. mutable structures tend to be more performant but harder to add parallelism to, and harder to reason about (leading to more copying than strictly necessary). Rust in particular has different ideas here.
I think the jury is still out on whether Rust will in practice tend to promote code that is faster or slower than C++. Of course any given project in Rust could be rewritten in C++ to be just as fast, or perhaps faster. But that's not what happens in the real world. Human factors matter, path dependence matters, affordances matter.
So it doesn't produce more efficient machine code, but it does open up new opportunities for optimization at a higher level.
I would even say that the room for improvement is potentially greater for rust than it is for C/C++, due to the type system. It hasn't been taken advantage of much yet, but MIR is one of the first steps to do so. It's an intermediate stage representation, like llvm's IR, but with all type resolution intact. There are plenty of known and even formally proven code optimizations that can only be used if certain guarantees are proven (such as the guarantees made by a strong type system).