Maybe. Everybody assumes that once WASM gets a GC framework that their favorite language, e.g. Python, will become a first-class citizen. But I suspect this won't come to pass for two related reasons:
1) There's no such thing as a universal GC. GC semantics differ across languages because the semantics matter; language developers make different choices. For example, some GCs support finalizers, others don't. Some with finalizers support resurrection, some don't; likewise, some languages specify a well-defined order for finalization (e.g. Lua defines it as the reverse order of allocation).
2) Similar to GC, there are other aspects that will prevent popular languages with complex runtimes from being compiled directly to WASM without altering language semantics or the runtime behavior relative to the standard, native environment. For example, eval.
So even with GC, the choices will likely remain the same as they are now: if you want the full experience of your favorite, rapid-development language within the WASM virtual machine, you must incur runtime overhead, up to and including double virtualization. Or, alternatively, you must contend with a bifurcation in a language ecosystem--native semantics vs WASM semantics. This will all be compounded by how programmers typically treat even the slightest differences, compromises, or concessions in behavior or performance as ritual impurities to be shunned. Ultimately, I don't expect the current status quo changing--languages other than statically compiled, strongly typed, non-GC'd languages like C, C++, Rust, or similar seeing much more usage in WASM environments than they already do, either browser-side or server-side.
I think people don’t distinguish between static languages with GC and dynamic languages. Static languages will run well, they already compile to binary or bytecode. My guess is that Java and C# could compile to WebAssembly, or JIT or AOP would be relatively small.
Dynamic languages need to read source and either interpret or JIT it. The result is much larger runtime and worse performance. It will probably always be worse than running JavaScript. A few people will want to use Python but it won’t be common.
GraalVM’s Truffle project seems to get away quite well with a universal GC implementation.
With it, one can create a competitively fast language-specific runtime simply by creating an AST-interpreter: so far the more complete ones being JS, Ruby, R, Python and even LLVM bitcode — all of them mapping to the JVM’s state-of-the-art GCs. This allows easy polyglot programs as well, where the JIT compiler can even optimize across language boundaries!
I think that languages with more niche control flow/GC semantics should just accept the tradeoffs and find some other way around - which is not unheard of in case of WASM, if I’m not mistaken things like stack pointers also have limitations in WASM vs the native C world.
That's possible partly because the Java GC featureset is nearly a superset of what other GC runtimes offer, and partly because Truffle/Graal integrate deeply with the JVM compilers for things like barriers.
Would this mean that we might end up with a new language that compiles to WebAssembly with GC? Logically, it would be statically type since anyone wanting a dynamically type language could just use Javascript.
Existing compilers for GC'd languages that target WebAssembly today have to use inefficient schemes to make their runtimes work, making the website slower than they would be otherwise, which is pretty much the entire point of OP.
And anyway, regarding "lack of GC in WASM made it appealing" -- support for high level languages with GC semantics was always a long-term goal for WebAssembly and GC was thought about by the relevant parties long before the 1.0 spec was even ratified (the initial placeholders were added as early as 2017, 2 years before 1.0 ratification); it was just not within scope for the earlier versions because it's a pretty big topic, including many things that aren't even wholly GC related e.g. value types. But this isn't surprising either; most of the earliest implementations and concerned parties were browsers, and the interactions between WebAssembly and JavaScript's memory models, along with the popularity of Javascript-targeting compilers (which suffer from many similar contortions), meant that GC was always a pretty obvious "This is a thing we need to think about in the long run" feature.
You are correct, but I disagree with the premise. Javascript and the entire ecosystem is horrible and only came to rise because there was no other option.
For the first time ever we do a have shot of making something better and our goal is to adapt it to the lowest common denominator? We most certainly don't make it easy for ourselves...
It shouldn't. It's goal is to continue running in the browsers and to have proper interactions with browser objects like the DOM. And those are garbage-collected by the browser. So you need at least some GC support in wasm to tell it that an object is released and to check if the object is still held by wasm runtime.
> and our goal is to adapt it to the lowest common denominator
How is garbage collection the lowest common denominator?
Isn't it more likely that if there never was first-party GC, everyone who wants GC is just going to bundle a bad one instead, making those sites _slower_?
I don't understand this logic. If you take gc away the people who would leak using gc will leak using malloc instead. Unless you're actually proposing that those people shouldn't be allowed to ship software?
As opposed to now, where they might be using even more memory because bring-your-own-GC solutions are that much more inefficient, as outlined in the article?
