4 ms·

"why is Go compelling as a source language for WASM?" As near as I can tell, the answer is that it is supported, and has been working now for many versions. S

by jerf 2y ago

"why is Go compelling as a source language for WASM?" As near as I can tell, the answer is that it is supported, and has been working now for many versions. See the short list of "production" languages here: https://github.com/appcypher/awesome-wasm-langs https://github.com/appcypher/awesome-wasm-langs And read the sections carefully; you might think your $FAVORITE_LANG must be in the "stable for production usage" section given how big it is but it's full of a lot of languages with small communities. The really big names are mostly in the "unstable" category. I can verify that I've toyed with some WASM support in a few languages now, and it is often not even functional, or takes vast effort to set up far above and beyond the official tutorials. You'll see a steady stream of stories on HN over the years about how this language or that language supports it, but in many cases those should be understood not so much as a commitment of support, but as a snapshot, that in that moment, it worked, but it may not work next week. It's still true that Go produces big binaries. Official WASM garbage collection support may shrink that at some point though it'll still be larger than other languages for the goroutine runtime support. Not only is a bare minimum "Hello World" a couple of megabytes off the top, the Go WASM executables grow quickly as you add libraries. It rapidly becomes usable only for situations where you are guaranteed very high bandwidth for all users. Such situations exist, but is certainly a major limitation. (Though at least it does cache well, if you are even slightly careful with caching.) So, to summarize, I'd say that it's not that Go is awesome and amazing, but that vast swathes of the competition are still quite bad.

bloppe 2y ago
I thought the runtime was essentially a fixed cost, and that a compiled Go binary would be similar in size to the native binary for the same source tree. Are you saying it grows faster?
- jerf 2y ago
  Well, "normal" Go binaries grow somewhat quickly as you add libraries. I don't think WASM is growing faster, it just stings more when you're looking at transferring them in realtime over a network. A 20MB binary is not really anything to a modern system, not even a Raspberry Pi. But a 4MB WASM executable can still hurt. (Though, sadly, only if you care. I just double-checked CNN's website, and given that it autostreams video it's hard to give a concrete "it took this much to load the site", but if I look at how much data was transferred before the home page stopped jumping around and rerendering and unblocking grey boxes and spinners, it was around 20MB.)
  - baq 2y ago
    laughs in kubectl
pr353n747-0n83 2y ago
The most basic understanding of programming language runtimes is sufficient to guess the entire Production-tier list. There isn't any need to talk down to us about $FAVORITE_LANG
- jerf 2y ago
  I strongly disagree. I'd expect it to me much larger by now, at least, based on my expectations and not my experience. And once you clear the small-community languages out of the "stable" list I think it's underpopulated there as well; it's basically just .Net, .Net through C#, and .Net through F# (which I'm sure is more the .Net than the F#, no offense intended to the F# team). Way, way more of the languages I can name off the top of my head in "unstable" than I'd expect. And while I don't intend this to be offensive to anyone either, WASM is just generally moving way slower than I expect. Given how many years that has been true at this point I must conclude it is being quite underinvested in, or, to put it another way, I'm blaming Google and peers for underinvesting, not the people working on it. More power to the people working on it, their skill is evident.
martinald 2y ago
Not true. I've built multiple production apps with Blazor WASM. Works great. Only drawback is the continually delayed multi threading support, but given native JS multi threading is far from ideal it's not a huge drawback.
wjfuasdf 2y ago
How did you miss: https://github.com/golang/go/issues/71134 https://github.com/golang/go/issues/71134
- jerf 2y ago
  How do you think?

by jerf 2y ago

bloppe 2y ago

I thought the runtime was essentially a fixed cost, and that a compiled Go binary would be similar in size to the native binary for the same source tree. Are you saying it grows faster?

jerf 2y ago
Well, "normal" Go binaries grow somewhat quickly as you add libraries. I don't think WASM is growing faster, it just stings more when you're looking at transferring them in realtime over a network. A 20MB binary is not really anything to a modern system, not even a Raspberry Pi. But a 4MB WASM executable can still hurt. (Though, sadly, only if you care. I just double-checked CNN's website, and given that it autostreams video it's hard to give a concrete "it took this much to load the site", but if I look at how much data was transferred before the home page stopped jumping around and rerendering and unblocking grey boxes and spinners, it was around 20MB.)
- baq 2y ago
  laughs in kubectl

pr353n747-0n83 2y ago

The most basic understanding of programming language runtimes is sufficient to guess the entire Production-tier list. There isn't any need to talk down to us about $FAVORITE_LANG

jerf 2y ago
I strongly disagree. I'd expect it to me much larger by now, at least, based on my expectations and not my experience. And once you clear the small-community languages out of the "stable" list I think it's underpopulated there as well; it's basically just .Net, .Net through C#, and .Net through F# (which I'm sure is more the .Net than the F#, no offense intended to the F# team). Way, way more of the languages I can name off the top of my head in "unstable" than I'd expect. And while I don't intend this to be offensive to anyone either, WASM is just generally moving way slower than I expect. Given how many years that has been true at this point I must conclude it is being quite underinvested in, or, to put it another way, I'm blaming Google and peers for underinvesting, not the people working on it. More power to the people working on it, their skill is evident.

martinald 2y ago

Not true. I've built multiple production apps with Blazor WASM. Works great. Only drawback is the continually delayed multi threading support, but given native JS multi threading is far from ideal it's not a huge drawback.

wjfuasdf 2y ago

How did you miss: https://github.com/golang/go/issues/71134 https://github.com/golang/go/issues/71134

jerf 2y ago
How do you think?