alt Hacker NewsJust checked and out of the 3 major non-JS GC languages, Go and .NET aren't planning to support WASM GC due to non-matching semantics. There's an implementation for Java - TeaVM, which is an AOT Java compiler, that does have production grade support, but isn't aiming for full Java compatibility (not sure what this means in practical terms).
Native interop with JS objects on the JS GC heap isn't supported as well.
Replies
This is another good example that not all GCs are born alike, even though its is common to place them on the same basket.
WASM GC is a MVP, only usable by languages whose GC requirements overlap with JavaScript's GC.
Java has it easier than either Go or C#, because the Java and JVM specification is actually silent on how GC should be implemented, hence why there are so many implementations to chose from across JVMs.
Outside the browser there is hardly any value, just use JVM or CLR directly.
> Native interop with JS objects on the JS GC heap isn't supported as well.
Isn't that what the i31 type is for, that extra bit is a tag for...something, native GC'd object perhaps? Not so clear on that myself as Java's object model (minus synchronized) slots in perfectly so my Java 1.0 -> wasm compiler doesn't need it but that's my limited understanding of what it's for.
Links to discussions about why WASM GC in its current state is not suitable for .NET: https://github.com/WebAssembly/gc/issues/77
What should be improved: https://github.com/dotnet/runtime/issues/94420