It's currently still a stage 1 proposal, while we've been waiting for years for other proposals to be merged. The last time a proposal was actually finished was over 2 years ago.
https://github.com/WebAssembly/proposals
https://github.com/WebAssembly/proposals/blob/main/finished-...
https://github.com/WebAssembly/proposals
You can also check out:
https://webassembly.org/roadmap/
And for Go, the proposal project on Github has many interesting conversations from the devs.
And as a reminder to anyone interested in using Go WASM, it’s experimental and does not come with the same compatibility promise as Go itself:
It's in phase 3 (Implementation Phase): https://github.com/WebAssembly/proposals
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?
WASM already has a GC proposal[0] which is already at the "Implementation stage"[1] so it looks like this IS going to happen, although it's uncertain if language runtimes like Go will actually make use of the feature, or what.
[0]: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...
[1]: https://github.com/WebAssembly/proposals
A glance of the overview and spec seems to indicate that WASM will provide some primitive data types, and any GC language can build their implementation on top of it. As I understand it, it's heavily based on Reference Types[3], which allows acting on host-provided types, and is already considered part of the spec [4]. It doesn't remove the need for the 5 different runtimes to have their own GC, but it lowers the bulk that the runtimes need to carry around, and offloads some of that onto the WASM runtime instead.
[3]: https://github.com/WebAssembly/reference-types/blob/master/p...
[4]: https://github.com/WebAssembly/proposals/blob/main/finished-...
[1]: https://github.com/WebAssembly/proposals [2]: https://github.com/WebAssembly/meetings/blob/main/process/ph... [3]: https://webassembly.org/roadmap/ [4]: https://github.com/WebAssembly/gc
https://github.com/WebAssembly/proposals
You can see that "interface types" is at "Phase 1 - Feature Proposal (CG)", so still early days.
And there's a link to the proposal here, for people like me who don't know about it: https://github.com/WebAssembly/interface-types
"During this phase:
"One or more implementations proceed on prototyping the feature to the point that a comprehensive set of tests can be added.
"A test suite is added. These tests need not pass the reference interpreter at this point, but should pass on some implementation."
https://github.com/WebAssembly/meetings/blob/main/process/ph...
Here's the proposal:
https://github.com/WebAssembly/gc
And you can see it's being actively worked on:
I think that might also change as they add proposal and roadmap items like "direct access to the DOM"[1] to WASM.
Proposals: https://github.com/WebAssembly/proposals
Roadmap: https://webassembly.org/roadmap/
[1] https://github.com/WebAssembly/interface-types/blob/master/p...
Edit: Overall, the proposals seem to be pushing WASM closer to being a general purpose VM (VM as in JVM, not KVM).
* reference types * interface types * exception handling * typed function references * garbage collection
I.e. most WASM proposals must be accepted before we can use the DOM from WASM... by the pace it's been moving forward, I guess this will take at least several years (3-4+).
As in (emphasis mine): "This means that there are important features we know we want and need, but are post-MVP" [1]
As in: "a Minimum Viable Product (MVP) for the standard with roughly the same functionality as asm.js, primarily aimed at C/C++;"
It's good that you specified "vital" when talking about "all" aspects. Where vital is basically "let's run MVP in an isolated sandbox with little-to-no interoperability with the rest of the browser". Because the rest of the vital things like "basically everything" [3] [4] are still MIA.
But yeah, I mean, the modern web was built on a language designed in 10 days, so I shouldn't complain, should I.
[1] https://github.com/WebAssembly/design/blob/master/MVP.md
[2] https://github.com/WebAssembly/design/blob/master/HighLevelG...
[3] https://github.com/WebAssembly/design/blob/master/FutureFeat...
WebAssembly proposals tracker: https://github.com/WebAssembly/proposals
WebAssembly reference types (https://github.com/WebAssembly/reference-types/blob/master/p...) looks like the blocker for a lot of things, and it's in the final spec phase at least.
In Chrome, it's behind a flag since 78, which went stable in Oct 22 2019: https://chromestatus.com/features/5166497248837632 But also under active development? https://bugs.chromium.org/p/v8/issues/detail?id=7581
Supposedly implemented in Firefox two years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1444925
Nothing in Safari, of course.
Where is it now though?
I don't know what magic you're talking about - we're simply waiting for WASM to standardize GC, SIMD, tail calls etc, you can read more here[0]; and to get the execution optimized like V8 did over the past 10 years[1] (WASM on V8 gets most of these gains by default as a bonus).
I already said why I want WASM: because it provides a good sandbox and opens most ecosystems through safe and typed interop. I don't care about ES modules in particular - I care about ES modules, Ruby modules, Python modules, Prolog modules, Fortran modules, C modules, Rust modules, AssemblyScript modules, COBOL modules, Erlang modules, F# modules, Java modules, and so on - at once. Finally a future where I can use and trust any library and not get limited to the language I use (if I don't want to spend most of my time fighting and securing C ABI interop, if at all humanly possible) is there.
Phase 4 requires a second implementation, and then we will ship it.