JavaScript and Rust are so opposite in their goals and design that I wonder why something like this is written...
I have professionally come across many website backends that were developed in Javascript. Over time we are seeing projects that add more robustness, performance, and ability to support in the form of Typescript and now Deno.
With WASM becoming mainstream and the growing maturity of the Rust ecosystem, it appears to be a solid choice for backend systems and potentially emerging frontend use cases.
If they wanted something better for the backend (for robustness of performance reasons) there are other alternatives much better suited for the vast majority of backends. For instance, C#.
WASM is not needed for the backend, so that is not the reason either. For frontend, I can see it for some pages (I used it myself), yes, but there are also other languages that can target WASM.
You also mention maturity of Rust, but other languages in its domain are more mature, so that cannot be it either.
WASM is not required, but having a sandbox around native (e.g. Rust) code seems like a good idea, and it allows you to mix languages and opens other ecosystems.
No, it is not a good idea for backend where your processes and code are trusted because it does not come for free (it comes with a big performance penalty).
Mixing languages does not require WASM in native code either. It has always been done through the C ABI.
No process nor code is trusted in my company. The performance penalty is negligible compared to the multi-million risks, and WASM execution can be optimized a lot as it goes past MVP.
I don't know how to import a ES6 module using C ABI.
> No process nor code is trusted in my company.
Then you cannot use any modern computer in your company. Much less hypercomplex systems like Node, v8 and JITs in general.
> compared to the multi-million risks
What "risks"? What standards are you following? Insurance?
> WASM execution can be optimized a lot as it goes past MVP.
Citation needed. There is no magic.
> I don't know how to import a ES6 module using C ABI.
So that is why you want WASM?
I don't know what magic you're talking about - we're simply waiting for WASM to standardize GC, SIMD, tail calls etc, you can read more here[0]; and to get the execution optimized like V8 did over the past 10 years[1] (WASM on V8 gets most of these gains by default as a bonus).
I already said why I want WASM: because it provides a good sandbox and opens most ecosystems through safe and typed interop. I don't care about ES modules in particular - I care about ES modules, Ruby modules, Python modules, Prolog modules, Fortran modules, C modules, Rust modules, AssemblyScript modules, COBOL modules, Erlang modules, F# modules, Java modules, and so on - at once. Finally a future where I can use and trust any library and not get limited to the language I use (if I don't want to spend most of my time fighting and securing C ABI interop, if at all humanly possible) is there.