Plus, the concurrent model of Go doesn't really shine if you run it in a single threaded configuration (which is most likely to be the case in wasm).
I might be missing something but to me it sounds like pure hype to put go and wasm together.
Even with GOMAXPROCS=1 (1 CPU running Go code), it's very liberating to be able to write blocking Go code and not worry about callbacks or async/await and let Go's runtime deal with it all while you write concurrent code.
I'm not, it's just that the most appealing feature of Go is it's ability to use parallelism for concurrency with a decent overhead, which makes it straightforward to scale vertically.
> Even with GOMAXPROCS=1 (1 CPU running Go code), it's very liberating to be able to write blocking Go code and not worry about callbacks or async/await and let Go's runtime deal with it all while you write concurrent code.
IMO, Async/await is a much cooler pattern than Goroutine + channels do do concurrent stuff on one thread. I find it way easier to use, and less error prone. The drawback is that you need a different paradigm when you want to take advantage of parallelism.
Of course it's a matter of personal preferences, but the prevalence of async/await in different programming languages indicates that at least I'm not the only one thinking this way :).
Running other languages(than JS) in the browser is interesting for sure.
a) binary portability - compile and ship WASM link/run on any machine with WASM VM - eg. package up to NPM and run trough any V8 target
b) extra sandboxing layer for security (it's designed for browsers where you are supposed to run non-trusted code)
c) portable APIs (assuming WASM targets expose the same underlying platform like node or w/e)
d) WASM is single threaded right now but from what I've seen it's a top priority for next release to spec out shared memory threads
a) and c) means it's portable on everything a JS VM runs on, which is not that much more than what Go runs on.
b) is legit, but that really sounds like an overkill.