The first iteration of garbage collection is now available in Wasm, but like the other proposals I’ve mentioned, it’s only enough to get things started. One important point for even this early iteration of Wasm GC is that you don’t pay for it if you don’t use it. Wasm programs that never use garbage collection will see no changes to their code.
Two things are coming next. The first is more robust features for Wasm GC, such as safe interaction with threads. Another is to have compilers that target Wasm and Wasm-ported runtimes utilize Wasm GC. For this to work, the compilers and runtimes in question will need to be modified. The Kotlin language, for instance, has introduced a Wasm implementation that uses Wasm GC, although it’s still considered an alpha-quality project.
The path to garbage collection reveals a pattern for other major Wasm features to come. Just having a feature defined formally in a spec or added to the available runtimes isn’t enough. All the languages that compile to Wasm must support the feature directly to make the most of it, and the timeline for that will vary with every language. That said, languages that can compile directly to Wasm (like Rust) will likely be quicker to add support, while those with a ported runtime (like Python or Go) will lag. Implementing support for new features is more straightforward for languages that compile directly to Wasm than for those that don’t.
