Hacker News Reader

Comment by potamic | Hacker News Reader

What about Go causes large binaries?

Go's "nothing is async because everything is async" model, combined with WebAssembly's (current) lack of support for stack switching and arbitrary goto, essentially mean that the compiler needs to insert extra code everywhere to support arbitrarily un/rewinding the stack.

This massively bloats binaries and means that go compiled to wasm is much slower than native speed, significantly more so than than the equivalent slowdown for c/rust.

see https://github.com/golang/go/issues/65440

Well, for one, you need the whole Go runtime.

Can that at least be a separate wasm file from some common URL so the browser can cache it?

Browsers don’t do that. Caches are not shared across sites.

Didn't expect that, but not very surprised. So short of the browser giving the Go runtime some special treatment, this sounds like a no-go.

Nit: they don't do that anymore, because cross-origin caches cause privacy problems. But they used to, and this news is still percolating through the industry.

Some of them still do, if someone is using an outdated enough browser :D for example Chrome <86 (released 2020).

You can't have dymanic linking of two C-like libraries compiled to wasm, because you would not be able to pass pointers around. Basically everything you compile to wasm becomes static binary which needs some bitfiddling to interact with.

Hm, so besides not having cross-site caching like ahoka mentioned, you can't even use some common fast CDN to host the compiled runtime.

It's more of a go problem than the wasm problem. Don't bundle such a big runtime and pass memory pointers around and you can have nice things.

Something beam-hosted with zero pointer sharing between nodes and smaller runtime maps to wasm much better.

It's also unfortunate for a lot of heavy JS libs out there that they can't be cached locally anymore, but security is important.

One WASM-related case I've actually encountered in the wild is Unity web. Similar problem as Golang, the runtime is heavy.

Can't be done until Wasm Components are widely supported by browsers and everything in wasmland moves at turtlespeed for various reasons...

Probably that Go has to ship heavier runtime (with its own GC etc)

Probably that. Kotlin waited until wasm GC was available and now has a compiler that relies on that. Kotlin wasm binaries can be pretty small depending on what libraries you use.

Probably a bit of work but there should be no reason why Go would not be able to do the same at this point.

.NET is still not using WASM GC for Blazor, because it doesn't support all the use cases in .NET runtime, that is the thing wiht having a single GC implementation for everyone.

People tend to think all GC are the same, they are not.

Reply on news.ycombinator.com