Another good article: https://v8.dev/blog/wasm-gc-porting

This is what I want most in future Go version iterations.

Once Go ships with Wasm-GC support, the binaries produced should be super small... eager to see how the Go team progresses on this!

CC @golang/wasm

After looking briefly at various articles about this, I expect this will be an enormous amount of work, almost comparable to writing an entirely separate compiler. There would have to be special cases at many levels within the compiler. I would also love to see this, but I think it will be hard without considerable effort.

+1 to what @johanbrandhorst said. Another big blocker to this is the fact that the Wasm GC, IIUC, doesn't yet support interior pointers, which are ubiquitous in Go code.

Who do I need to pay to make this happen?

tinygo is great, but cannot handle anything beyond basic go apps.

Please. God. This.

I think folks are presuming that WASM-GC would mean that the generated programs would change a lot. What changes are folks presume? From the comments above, there is the perception that it would make the binaries smaller, but that's not the case. The code to run the GC is tiny in compared to the rest of the program.

I am ignorant, so please excuse that fact, but wouldn't completely removing the 1.5mb+ of additional GC golang bulk, only reduce WASM size?

Where are you seeing this 1.5MB?

@daveshanley removing the Go GC from the WASM build will indeed obviously reduce its size, but I have found no information about the "1.5mb+" GC size allegation

bump: any plan for this compiler feature

@omar391 No plans at present, the model of WASM-GC isn't compatible with the Go language.

@evanphx could you provide reference links to documentation about that?

wasm is fortunately still work in progress. If someone is brave enough feel free to submit a proposal for interior pointers