WebAssembly in Go: reasons for design decisions

From my experience with other languages (C++, Rust), a WebAssembly module is supposed to be used like a library, a binary file exporting a set of functions.
Go however, treats WebAssembly as an executable. At runtime, functions can be registered in the global JS object. Functions are callable as long as the main method is running. Everyone, including me, uses the wait-on-channel-pattern to make the main method run forever. But… why?

I searched through the entire 500+ comment long initial issue for WebAssembly support (https://github.com/golang/go/issues/18892). It’s quite an interesting read, neelance stepping up and giving it a try, and then letting everyone take part in his journey! I bow to you neelance!

But nowhere I can find an explanation why Go does not comply with the WebAssembly export functionality.
I am not saying that’s bad, actually the dev experience is quite good, interop between Go and JS is great.
I’m just wondering what the reasons for that decision were.
Does anyone have an idea? Maybe due to the GC?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.