How is it "production-ready" anything if WebAssembly itself isn't even out of MVP stage yet?
Because the "MVP" stage is itself production ready, which is why it was stabilized in browsers 3 years ago. Also, some non-MVP features are almost stable, e.g. atomics are now enabled on chrome by default IIRC.
WASI, the posix-like system interface ABI, is still technically a "snapshot", which has made me slightly concerned wrt stability given that Rust can compile to WASI even on the stable channel, but hopefully even the full stable version is backwards-compatible with snapshot-1.
> Because the "MVP" stage is itself production ready
> some non-MVP features are almost stable
> the posix-like system interface ABI, is still technically a "snapshot"
So... It's not production ready.
WebAssembly's MVP release was primarily targeted at the ... web. It is production ready in all (vital) aspects concerning execution in a browser.
As in (emphasis mine): "This means that there are important features we know we want and need, but are post-MVP" [1]
As in: "a Minimum Viable Product (MVP) for the standard with roughly the same functionality as asm.js, primarily aimed at C/C++;"
It's good that you specified "vital" when talking about "all" aspects. Where vital is basically "let's run MVP in an isolated sandbox with little-to-no interoperability with the rest of the browser". Because the rest of the vital things like "basically everything" [3] [4] are still MIA.
But yeah, I mean, the modern web was built on a language designed in 10 days, so I shouldn't complain, should I.
[1] https://github.com/WebAssembly/design/blob/master/MVP.md
[2] https://github.com/WebAssembly/design/blob/master/HighLevelG...
[3] https://github.com/WebAssembly/design/blob/master/FutureFeat...