This comment repeats a fundamental error and misunderstanding: WASM is (currently) not able to be a compilation target for an efficient GC implementation. It lacks features needed to be able to implement GCs reasonably, like memory barriers.
So 1. is out of scope if you don't want a bloated super slow language runtime running on top of WASM (like e.g. Blazor).
The issue is known since the very beginning. Nobody in charge is willing to solve it.
Also 2. is not happening, even it was discussed also since many years.
But that makes actually "sense" form the WASM people's perspective: WASM was never meant to by concurrency to JS in the browser!
WASM is merely a performance booster for where JS sucks (like numerical code).
That WASM will allow to use other languages (and their ecosystems) in the browser is just a day dream of some. The companies behind "the web platform" won't give up on their billions worth of investments into the JS ecosystem.
So no, GC languages other than JS won't ever run "natively" on the browser in a meaningful way. WASM is crippled on purpose in this regard, and as long as the current stack holders continue to control "the web platform" this won't change.
> WASM is (currently) not able to be a compilation target for an efficient GC implementation.
Even if it was, there are other problems that mean the dream of being able to use alternative languages and runtimes on the web is far off, if it even ever happens at all.
As a hobby I'm writing a design doc for an alternative non-web system design. It enumerates some of those problems and proposes solutions, along with other dissatisfying aspects of the web (e.g. the unimplementably large size of the web specs).
It's designed to be a very lightweight set of layered specs and projects that are way cheaper to implement than HTML5, can be developed and deployed incrementally whilst providing value from the start and which places other runtimes on a level playing field vs HTML. It also addresses many of the details you need to tackle for any serious web-like system such as transiency, sandboxing, tabbed WM, cache privacy, portability and hyperlinking.
I sent it to Ian Hixson who found it interesting, but of course the sticking point is funding models. Being way cheaper to implement than the web doesn't mean it costs nothing to implement. The web benefits from the largesse of rich patrons, any alternatives would need to either find a patron or find some business model that let it grow in quiet corners until it was strong enough to be fully competitive.
> This comment repeats a fundamental error and misunderstanding
Unless I'm mistaken, you seem to be vigorously agreeing with me about performance:
I said that implementing a GC inside WASM right now is possible (eg Blazor, wasmer-go) but slower and bigger than if a GC was built into the wasm virtual machine.
You said:
> WASM is (currently) not able to be a compilation target for an efficient GC implementation. It lacks features needed to be able to implement GCs reasonably, like memory barriers. So 1. is out of scope if you don't want a bloated super slow language runtime running on top of WASM (like e.g. Blazor).
... Which reads me like, "its possible (eg blazor) but doing it the current way makes it bloated and super slow". I agree!
> Also 2. is not happening, even it was discussed also since many years.
As another commenter pointed out, wasm-GC is in the implementation phase. Its already supported in Firefox and Chrome, though in both cases behind a feature flag.
What I've understood was that GC in WASM "is totally possible right now". Which it isn't.
> As another commenter pointed out, wasm-GC is in the implementation phase. Its already supported in Firefox and Chrome, though in both cases behind a feature flag.
I don't believe anything meaningful will happen there. The "GC support" was "announced" right at the same time WASM was introduced. Half a decade later, and nothing happened. Even a high-end GC is right there, namely in the JS runtime, and all that would be needed to use it would be handing over a handful of API wrappers.
I've read a little bit on that topic last year as I wanted to know about the current state and why it takes forever to implement this triviality. But I can see there are all over the place only stalling tactics… People are coming up with infinite "but"s. Since years now. More or less since the first day WASM exists.
I came therefore to the conclusion: This multi-language promise of WASM just won't happen (in any meaningful way). The people behind "the web platform" (Google) are mostly not interested in making web applications just a poor man's "Java WebStart" and "the web platform" just an arbitrary replaceable language runtime. At the very moment you could run any language (and it's ecosystem) on the web there wouldn't be any real initiative to invest into web-apps on "the web platform"—and Google's empire would fall apart.
> What does concurrency have to do with any of this?
Nothing I guess. :-D
I am not a native speaker. I fell for a "false friend"...
I wanted to say: "WASM was never meant to be competition to JS in the browser."
> I wanted to say: "WASM was never meant to be competition to JS in the browser."
I hear what you’re saying, but there’s no evil javascript lobby group running around trying to stop other languages from becoming viable in the browser. Google doesn’t care - they don’t make less money from advertising if Go becomes a viable language for frontend web applications. Google, probably more than any of the other big tech companies, is led by engineers. And I think lots of googlers really dislike javascript and would love to have other viable options.
So why has it taken years to get GC in wasm? After attending a few IETF meetings, I’m increasingly convinced that decisions take time proportional to the number of people in the room. The wasm working group includes all the browser vendors - Google, Microsoft, Apple, Mozilla. and a lot of companies and individuals. That’s going to make any big changes to wasm take longer than everyone wants, even if everyone is on board with the proposal.
Rust is suffering from the same thing. Their inclusive decision making process has made language evolution slow to a crawl in the last few years as more and more people have put up their hands to get involved. There’s too many cooks in the kitchen and they’re getting in each other’s way.
Another take on this is Hanlon’s Razor: Never ascribe to malice what can be explained by stupidity. Nobody is trying to undermine the GC proposal. It’s just slow going. Implementations exist already (behind feature flags). Hopefully wasm-gc is released before the end of the year. We’ll see.
So 1. is out of scope if you don't want a bloated super slow language runtime running on top of WASM (like e.g. Blazor).
The issue is known since the very beginning. Nobody in charge is willing to solve it.
Also 2. is not happening, even it was discussed also since many years.
But that makes actually "sense" form the WASM people's perspective: WASM was never meant to by concurrency to JS in the browser!
WASM is merely a performance booster for where JS sucks (like numerical code).
That WASM will allow to use other languages (and their ecosystems) in the browser is just a day dream of some. The companies behind "the web platform" won't give up on their billions worth of investments into the JS ecosystem.
So no, GC languages other than JS won't ever run "natively" on the browser in a meaningful way. WASM is crippled on purpose in this regard, and as long as the current stack holders continue to control "the web platform" this won't change.