Nothing, that is after all how CLR was designed, just lets not pretend it is something new.

JVM wasn’t just for Java developers (Kotlin, Clojure, Ruby could compile to it); but it was easiest for Java, and other languages didn’t elect to build on the JVM interface by default, rather adopting POSIX (and either a custom bytecode or assembly) as the interface.

WASM likely won’t convince all languages to switch to its bytecode by default. Its adoption story requires enough people to maintain this non-standard compilation pipeline.

Which is fine, but beyond the bytecode, the productivity will only be maintained if it offers an equal or superior interface to POSIX. Right now, WASI is not it. A lot of basic elements are experimental, like file seek, multi-process, threads, SIMD, GPU programming…

People will believe the hype, miss the caveats, use it at work, and have their project fail. Companies will blacklist the technology.

In my mind, it is too early for them to be so publicly dithyrambic. All WASM publications should link to a page that details all WASI features that are still experimental.

"JVM but for everyone who isn't a Java developer" would be good but WebAssembly isn't really suited for it. It works for some static native-code targeting languges (C, C++, Rust, Zig, etc) but doesn't work well for languages that most application developers use (.NET languages, TypeScript/JavaScript, Python, Clojure, Java, Ruby, etc).

> "JVM but for everyone who isn't a Java developer" would be good but WebAssembly isn't really suited for it. It works for some static native-code targeting languges (C, C++, Rust, Zig, etc) but doesn't work well for languages that most application developers use (.NET languages, TypeScript/JavaScript, Python, Clojure, Java, Ruby, etc)

.NET/Java/Clojure, maybe not. Ruby and Python work via an interpeter for the platform, just like they do on JVM/.Net, except that, unlike JVM/.NET, in both cases they can use the normal C-based interpreter, compiled for WASM.

You can do it, but it remains to be seen if we get a lot of use cases where there are more positive than negative tradeoffs from targeting a VM implementation to WebAssembly and then running a VM inside a VM that way. I guess eg Python could be useful in cases where you want to use it as a glue language between WebAssembly components...