The answer was kind of known before hand. It was to enable the use of GCed languages like Python on Ruby to create WASM applications. Meanwhile, non-GCed languages like Rust, C and C++ were supposed to continue to work as before on WASM without breaking compatibility. This is what they seem to have finally achieved. But I needed to make sure of it. So, here are the relevant points from the WASM GC proposal [1]:

  * Motivation
  - Efficient support for high-level languages
      - faster execution
      - smaller modules
      - the vast majority of modern languages need it

  * Approach
  - Pay as you go; in particular, no effect on code not using GC, no runtime type information unless requested
  - Don't introduce dependencies on GC for other features (e.g., using resources through tables)

[1] https://github.com/WebAssembly/spec/blob/wasm-3.0/proposals/...

Note that the high level language needs a sufficient abstraction in its own runtime to allow substituting the Wasm GC for the runtime’s own GC. Work has been done for Java and Kotlin, but Python, C#, Ruby, Go can’t yet use the Wasm GC.

Agreed. That's what I guessed too. WASM GC is probably a low level component which high level languages can wrap to get their native/idiomatic GC behavior.

> Work has been done for Java and Kotlin

I'm unaware of this development. What did they do? Did they create an interface to the GC specification in the draft proposal?

Well, for Java it's actually a separate compiler that targets Wasm and integrates with WasmGC: https://github.com/google/j2cl The Google Sheets team used it for their calc engine: https://v8.dev/blog/wasm-gc-porting

For Kotlin it's similar but the compiler backend is from Jetbrains themselves, targets Wasm and adapts the Kotlin runtime to use WasmGC: https://kotlinlang.org/docs/wasm-overview.html. https://seb.deleuze.fr/introducing-kotlin-wasm/ has some low level detail on how Kotlin works with WasmGC.

A bit more on Kotlin/Wasm here, seems like also Dart/Flutter uses WasmGC: https://developer.chrome.com/blog/wasmgc#kotlin_wasm

https://github.com/dotnet/runtime/issues/94420 has some notes on why C# can't use WasmGC (yet?).

Good info! Thanks!

to also consider this one https://github.com/6over3/zeroperl

Non-GCed languages will continue to manage memory themselves. Previously, GCed languages that wanted to run on WASM had to have an implementation of their runtime including GC compiled to WASM. The idea or hope here is that those languages can use the built-in GC instead and slim down the amount of WASM that needs to be delivered to run the application to only include a minimal runtime. The current scenario is closer to if a web app or node app built with JavaScript had to ship a significant portion of V8 with it to function.

This will probably benefit Java applets targeting Wasm the most considering the huge size of their JVM.

Would not be surprised to see the typeinfo needing shipped taking up more space than the internal GC implementation it replaced :)

Hopefully Go as well.

Here's a fun example of a language that takes advantage of this: https://spritely.institute/hoot/