I'm writing a new Wasm GC language because I'm so unsatisfied with the current options. I'm three months in, and so for it's mostly good.
WASM takes care of all the GC bits, but in turn you have to use its ref, struct, and array types for everything. Making vtables is straight forward. Fat pointers for interfaces require an object though, since you can't do your own pointer layout.
In web contexts GC should be great because browser GCs can work across DOM, JS, and WASM, so you can hold a reference to a node that you get via JS, and if you remove the node from the DOM and discard the reference, it'll be collected just like in JS.
The big downside is data transfer over the Wasm boundary requires a lot more copying with GC. Byte arrays like (array i8) are completely opaque to the outside, so you need to vend individual byte access functions to read data. On the WASI side, it only lowers to linear memory, so you need to allocate some from scratch space, then copy into GC structs and arrays. Strings are doubly awful because of this because you also have to deal with encoding.
GC also doesn't support multi-threading yet.
Some of this is supposed to be fixed by things like https://github.com/WebAssembly/design/issues/1569 and WASI lowering to GC types. stringref would have been great, but that appears to be dead for now.
So I'm on board and optimistic these things will get fixed, but GC is still a bit of a second-class citizen for now.
If you are interested in multi-byte access to GCed arrays, something similar can already be accomplished. You can hold the array data in Wasm linear memory, then have an object that wraps a pointer to it, and using JS code, associate a finalizer with that object that frees the related section of linear memory. It's essentially how FFI memory is handled in most native GCed languages.
I considered that, but it requires more pointer indirection and I'm supporting WASI as a first class target, so won't always have access to JS finalizers. I'm going with copying as simpler for now, praying that multi-byte access lands by the time my language is viable.
WASM takes care of all the GC bits, but in turn you have to use its ref, struct, and array types for everything. Making vtables is straight forward. Fat pointers for interfaces require an object though, since you can't do your own pointer layout.
In web contexts GC should be great because browser GCs can work across DOM, JS, and WASM, so you can hold a reference to a node that you get via JS, and if you remove the node from the DOM and discard the reference, it'll be collected just like in JS.
The big downside is data transfer over the Wasm boundary requires a lot more copying with GC. Byte arrays like (array i8) are completely opaque to the outside, so you need to vend individual byte access functions to read data. On the WASI side, it only lowers to linear memory, so you need to allocate some from scratch space, then copy into GC structs and arrays. Strings are doubly awful because of this because you also have to deal with encoding.
GC also doesn't support multi-threading yet.
Some of this is supposed to be fixed by things like https://github.com/WebAssembly/design/issues/1569 and WASI lowering to GC types. stringref would have been great, but that appears to be dead for now.
So I'm on board and optimistic these things will get fixed, but GC is still a bit of a second-class citizen for now.