[torginus]

Just 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.

[jaen]

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

[kittoes]

I'm not familiar with the current spec and those posts are from 6/3 years ago, respectively. Do you happen to know if anything has changed since?

[UncleEntity]

> 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.

[davexunit]

I'm not sure what they mean by "native" here but (ref extern) is for host references, JS or otherwise. The i31 type is for "immediate" values, things that can fit in 31 bits and thus don't need to be allocated on the heap.

[pjmlp]

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.