5 ms·

I would love if wasm got some more TLC from the go team. Output sizes are massive compared to rust or C. I think it’s just a matter of adding some tree shaking

I would love if wasm got some more TLC from the go team. Output sizes are massive compared to rust or C. I think it’s just a matter of adding some tree shaking … but probably easier said than done. I’ve been falling more and more in love with wasm … so many possibilities :)

todd3834 5y ago
I wonder how tinygo works for wasm. I’m not sure how much of the bloat is runtime (which I assume is smallish) vs how much of the standard library is just included by default.
- justinclift 5y ago
  Tinygo produces very small binaries (kb rather than mb), through using the LLVM tool chain (which does tree shaking), and only (presently) supporting a subset of the standard library. Plus their own (simplified) subset of the standard library, which is getting more comprehensive over time, but is nowhere near complete yet.
- pjmlp 5y ago
  You can have a go at it over here, https://ebiten.org/examples/ https://ebiten.org/examples/
kjksf 5y ago
I would like that too but probably wont happen. There are 3 big reasons for large Go binaries. 1. Unicode data is ~1 MB. It's needed to implement all the unicode-aware string functions like strings.EqualFold() 2. reflection. For reflection to work, every struct used in a Go program needs to have a description information that tells names and types of all fields. This adds up 3. Precise garbage collector also requires struct descriptions like reflection but even more information like: layout of stack frame for every function. Those are problems that could, in theory, be worked-around. A build could exclude Unicode info and functions that require it. A different garbage collector could be used that doesn't require knowing layout of structs and stack frames. Reflection could be changed to require explicit opt-in (99% of structs are not reflected upon). Realistically none of that will happen in the official Go implementation. For better or worse most of the work is sponsored by Google and Google runs Go on servers. With 512 MB of memory, it makes little difference if your binary is 10 MB vs 9 MB, especially if you compete with even more bloat (in runtime memory use, not necessarily binary size) of Java / Python / Ruby / Node. There are a couple of not-very-mature Go-like implementation that are trying to address this (tinygo, emgo) but they have long way to go.
- slimsag 5y ago
  I agree with everything you said. Reflection, I think, is the one that is quite difficult to address. The others - GC and unicode data - can be addressed through changes to WebAssembly in theory. For Zig, I developed a custom compression algorithm[0] for the Unicode data files needed to implement the same string functions - reducing the data size down to just 58 KiB. The same could certainly be applied to Go. [0] https://devlog.hexops.com/2021/unicode-data-file-compression https://devlog.hexops.com/2021/unicode-data-file-compression
- whoisjohnkid 5y ago
  great points. I’ve used tinygo, it is pretty awesome unfortunately the features I was using weren’t supported; I was utilizing some public key cryptography. I will have to check out emgo; first time I’m hearing about it.
- singularity2001 5y ago
  much reflection can also be done through the host environment especially since it has full access to the data and custom name sections

todd3834 5y ago

I wonder how tinygo works for wasm. I’m not sure how much of the bloat is runtime (which I assume is smallish) vs how much of the standard library is just included by default.

justinclift 5y ago
Tinygo produces very small binaries (kb rather than mb), through using the LLVM tool chain (which does tree shaking), and only (presently) supporting a subset of the standard library. Plus their own (simplified) subset of the standard library, which is getting more comprehensive over time, but is nowhere near complete yet.
pjmlp 5y ago
You can have a go at it over here, https://ebiten.org/examples/ https://ebiten.org/examples/

kjksf 5y ago

I would like that too but probably wont happen. There are 3 big reasons for large Go binaries. 1. Unicode data is ~1 MB. It's needed to implement all the unicode-aware string functions like strings.EqualFold() 2. reflection. For reflection to work, every struct used in a Go program needs to have a description information that tells names and types of all fields. This adds up 3. Precise garbage collector also requires struct descriptions like reflection but even more information like: layout of stack frame for every function. Those are problems that could, in theory, be worked-around. A build could exclude Unicode info and functions that require it. A different garbage collector could be used that doesn't require knowing layout of structs and stack frames. Reflection could be changed to require explicit opt-in (99% of structs are not reflected upon). Realistically none of that will happen in the official Go implementation. For better or worse most of the work is sponsored by Google and Google runs Go on servers. With 512 MB of memory, it makes little difference if your binary is 10 MB vs 9 MB, especially if you compete with even more bloat (in runtime memory use, not necessarily binary size) of Java / Python / Ruby / Node. There are a couple of not-very-mature Go-like implementation that are trying to address this (tinygo, emgo) but they have long way to go.

slimsag 5y ago
I agree with everything you said. Reflection, I think, is the one that is quite difficult to address. The others - GC and unicode data - can be addressed through changes to WebAssembly in theory. For Zig, I developed a custom compression algorithm[0] for the Unicode data files needed to implement the same string functions - reducing the data size down to just 58 KiB. The same could certainly be applied to Go. [0] https://devlog.hexops.com/2021/unicode-data-file-compression https://devlog.hexops.com/2021/unicode-data-file-compression
whoisjohnkid 5y ago
great points. I’ve used tinygo, it is pretty awesome unfortunately the features I was using weren’t supported; I was utilizing some public key cryptography. I will have to check out emgo; first time I’m hearing about it.
singularity2001 5y ago
much reflection can also be done through the host environment especially since it has full access to the data and custom name sections