For this case it's complicated because some runtime supports https://github.com/WebAssembly/threads which mostly contains things like the spec for atomic but not the actual "threads" specs and then some runtimes (i.e wasmtime) also supports https://github.com/WebAssembly/wasi-threads which is one version of the threads. But a new proposal came into play https://github.com/abrown/thread-spawn so ... it's complicated.
I still build a single-threaded binary for Firefox, and fallback to it if `SharedArrayBuffer` is `undefined` or if the `WebAssembly.Memory` constructor fails (some iOS devices might throw when `shared` is `true` due to a bug).
https://github.com/WebAssembly/proposals
You can also check out:
https://webassembly.org/roadmap/
And for Go, the proposal project on Github has many interesting conversations from the devs.
And as a reminder to anyone interested in using Go WASM, it’s experimental and does not come with the same compatibility promise as Go itself:
[0] https://github.com/WebAssembly/meetings/blob/main/process/ph...
So instead of:
`host -> call foo on guest -> return to host`
`host -> call guest main -> call foo on host -> host returns when ready -> guest calls foo when done`
FWIW the scheduler (so goroutines) don't work in go if you're not calling from an main, so anytime you call a custom export then try to use a goroutine you'll get panics.
10x size is about the blowup we see as well. It's also likely to be slower (some of the Tinygo authors said ~20% slowdown compared to tinygo) probably due to the simpler/smaller runtime and LLVM being better at optimizing.
Edit edit: from this comment it sounds like it is, as you say, just the general overhead of managing goroutine stacks. I wonder if TinyGo is more performant.