Java is a language with a particular view of the world, and the JVM is a heavyweight runtime for executing that particular view of the world. The core idea of the JVM is great, and WASM executes that without assuming anything about your language, or requiring a great big tightly integrated second-banana-to-the-host-language's-stdlib system library, or anything else Java-y.
The great wheel continues to turn. If your wasm environment is a thin wrapper around the host you need to worry about the underlying system. So expect to see more and more abstraction or a break in portability. Similarly WASM assumes a lot about your language: imperative, statically typed, limited polymorphism, no GC (for now). It's not a good target for JS or Perl6 or Smalltalk or Common Lisp.
WASM reflects the usual capabilities of a hardware-based CPU. Just like your usual hardware CPU cannot run Common Lisp directly, neither can WASM.
JS, Perl, Python etc. all run well on widespread CPU architectures like ARM and x64. And that's why they will run well on WASM too given an appropriate runtime for that language.
To sum it up, WASM assumes nothing about a language - it's just a CPU, albeit a virtual one.
Obviously Church Turing tells us all substrates are the same in power. So when we talk about running well on X we mean something else.
WASM is not like any CPU in common use today. It's a stack machine with structured control flow and strongly typed pointers. The instruction sequence is a graph. Memory is not a flat address space.
I wouldn't call it a stack machine. Constraints requiring static stack depth is designed to be converted to SSA which then gets efficient register allocation
My experience with CPython (a while ago now) was that it ran like a dog on POWER, and that if you didn't account for the idiosyncrasies of the architecture in the interpreter's implementation, running "well" was a pipe dream. Considering WASM actively masks the underlying architecture, what evidence is there that other managed runtimes will naturally run well on WASM?
That's an interesting and open question. Especially the ability to JIT the code on the fly, so it could travel, say, Java -> WASM -> Hardware path. It seems that it's technically possible [0] but there will be dragons.
Let's hope that will never happen because it will lead to an imminent WASM death by making it opinionated.
I would also suggest to officially separate WASM from any notion of API. So that any working group anywhere in the world could design whatever API they want/need - but it would not wreck the purity of WASM as a result.
WASM GC is already shipped with Chrome. Flutter is already compiling to WASM on the web and can execute with Chrome and apparently Firefox now, using the "native" GC instead of shipping one with the Dart runtime: https://docs.flutter.dev/platform-integration/web/wasm
EDIT : to clarify it, both Chrome and Firefox (nightly) require feature flags to enable WASM GC as of writing.
Last I checked, the GC primitives in WASM are rather low level, and are more for building a GC system on top of, rather than relying on it to be your whole GC.
What a perfect seppuku. RIP WASM, thou was fun while thou lasted.
The only chance of survival is to declare WASM GC a heresy and to largely ignore it until it rots away like Intel iAPX 432 did. But considering the financial model of the current WASM development this plan may be unrealistic.
Why? You can still implement a WASM runtime with no GC, and so it's just additional functionality for where's its desirable. Additionally, the GC spec is low level and allows for pluggable GC, and better defines the WASM memory model.
@foota, WASM GC is a bad development because it's opinionated.
For example, the nice WASM <-> CPU bijective mapping of capabilities is going to be lost. WASM GC now turns the WASM into something completely different, something in the rank of Java, .NET, Flash, Node JS, or Elang.
For any GC to work, there must be a notion of a component model that defines the type system and the rules of type interactions. This is a complex topic by itself with myriads of decisions and compromises to make. This means that the end result won't suite everyone, if anyone at all.
This will lead to WASM GC stagnation - it will be there but nobody will be using it because no one wants to loose the ground and compatibility with real CPUs. There may be some users like Dart or Flutter with their niche opinionated situations, but it's a drop in the ocean.
As the time will pass, WASM GC will be gradually becoming a burden as it does not come for free - it requires maintenance, patches, security fixes. In the end, browser vendors may proclaim the WASM a new "Flash", "Java Applet", "ActiveX" that should be eliminated due to overdesigned complexity, too wide API surface, and associated security risks.
Rinse and repeat, there is nothing new under the sun.
Well there needs to be an alternative... A GC implemented in WASM isn't ideal because it doesn't let you walk the stack so you need to make a second software stack which is slow, and it also increases the binary size a lot
As much as the broader programming world is loving WASM as a barebones VM and sandbox, it ultimately was created to further the interests of the organizations championing it and their desires and it's clear that making it a complete JS stand-in is the direction it is heading. GC is only a question of time.
And this why WASM is so great. No opinions on a language, APIs, or anything; just pure execution. Well, WASI and WASIX are APIs but they are not strictly obligatory.
