|
|
|
|
|
|
by habitatenergy
1300 days ago
|
|
|
I don't think WASM should/would unify the GC across memory models, that could be extremely problematic. The gist of the idea is polyglot languages can leverage libraries across many languages. The fastest code is the code that was already built (that you didn't need to write). It's unlikely applications would actually implement libraries from 5 different runtimes (they could, but shouldn't), and if they use RUST libraries, there definitely wouldn't be any GC anyway. The benefit of this tech is it allows a new language to leverage historical codebases quickly without needing to re-invent every common utility library. This will inevitably speed adoption of newer languages, zero code tools, etc .. and is the epitome of Proebstings law, which could also accelerate Proebstings (which is every decade) to being to approach Moores law (but I'm not specifically saying that will happen, only that it could). |
|
|
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-...