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.

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.

https://github.com/WebAssembly/proposals

> It lacks features [...] like memory barriers. ... WASM was never meant to by concurrency to JS in the browser!

What does concurrency have to do with any of this?