Hacker News Reader

Comment by trulyrandom | Hacker News Reader

It's interesting that none of the comments so far complain about the size of the binary (13MB!). Nodejs and Electron projects get flak for this all the time, but Go somehow gets away with it.

View on HN

I could definitely stand to strip the binary (saves about 2M), but the main issue is that (1) it's statically linked and (2) I actually pull in a surprising amount of dependencies for a ~100 line program. It uses an template parser & renderer; an HTML cleaner; a time formatter; an RSS/Atom parser; TCP, HTTP, and XML implementations; and extra handling for Unicode. Even then, 11M is a bit excessive.

However, the comparison to Electron is unfair. The base Electron package is well over 100M, more than 10x as large, and generally not statically linked. This binary also doesn't hog your RAM and CPU and GPU like Electron does.

While it could and should be slimmed down, I agree that the comparison to electron makes little sense.

I think the larger complaint about electron is the memory usage, not disk space usage. Go may have large binaries, but they run fast and efficient.

Exactly. Who cares about 13MB disk usage in this day and age? But RAM is still too easily exhausted on a workstation with a decent amount of multitasking going on.

Personally, it’s the slowness, not the memory use

This looks like it is intended to be run on a server, and it runs and exits once completed rather than continuing to run.

Criticisms of something that needs a semi-permanent allocation of my laptop's memory (like slack or Spotify) don't really apply.

Wow, I didn't know Go had large binaries. There's no reason it should though. As Go programs are compiled down to native code, if as the last step of compilation, the equivalent of unix strip (or the JavaScript world's tree shaking or the JVM world's ProGuard) was run, the binary would only have code that's actually used. Since Go is a relatively young language, it might be that implementing this was just not that high of a priority for the Go implementers.

Alternatively, it's possible that the executable size is large because it: (1) actually contains a lot of in-use code, or (2) contains media files. I know on Windows, it's common for people to make media files part of the .exe file. The Windows Portable Executable (PE) format makes it quite convenient to do this; and the Windows API has functions that make loading up files bundled as part of the .exe file as seamless as reading from the file system.

Also there are no media files embedded, the whole project is 130LOC + some html markup:

https://git.sr.ht/~sircmpwn/openring/tree/master/openring.go

Go binaries tend to be fairly static, relying very little on system libs. It also makes some size tradeoffs for better load times. Also, compared to NodeJS and Electron... it’s still tiny. Not that anyone cares so deeply anymore.

I imagine because go compiles to an actual native binary, whilst electron wraps a browser and a chunk of JavaScript in a zip file.

You can’t really say “go gets away with it” as though these languages are doing the same thing.

You're right. My observation was just that the discussions often don't go much deeper than "look at this big binary", so I was surprised to find none of that here.

I can't say I've personally ever seen binary size explicitly called out in an Electron slating thread. It's usually memory usage on a typical 8-16GB laptop, or battery drain in the cases of frivolous animated bells and whistles.

That's just my anecdata

The next time you notice a particular clichéd complaint missing from a thread, it might be better to not comment on its absence unless you actually want to have the same discussion all over again.

I’ve never seen anybody complain about binary size in Electron. Most complaints are about RAM and CPU usage.

Reply on news.ycombinator.com