5 ms·

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, bu

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.

apsdsm 7y ago
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.
- trulyrandom 7y ago
  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.
  - samb1729 7y ago
    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
  - yorwba 7y ago
    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.
sethetter 7y ago
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.
- SkyMarshal 7y ago
  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.
- jammygit 7y ago
  Personally, it’s the slowness, not the memory use
notatoad 7y ago
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.
winter_blue 7y ago
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.
- dewey 7y ago
  Related: https://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary https://golang.org/doc/faq#Why_is_my_trivial_program_such_a_... 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 https://git.sr.ht/~sircmpwn/openring/tree/master/openring.go
kabwj 7y ago
I’ve never seen anybody complain about binary size in Electron. Most complaints are about RAM and CPU usage.
jchw 7y ago
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.
Sir_Cmpwn 7y ago
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.
- willio58 7y ago
  While it could and should be slimmed down, I agree that the comparison to electron makes little sense.

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.

apsdsm 7y ago

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.

trulyrandom 7y ago
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.
- samb1729 7y ago
  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
- yorwba 7y ago
  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.

sethetter 7y ago

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.

SkyMarshal 7y ago
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.
jammygit 7y ago
Personally, it’s the slowness, not the memory use

notatoad 7y ago

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.

winter_blue 7y ago

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.

dewey 7y ago
Related: https://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary https://golang.org/doc/faq#Why_is_my_trivial_program_such_a_... 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 https://git.sr.ht/~sircmpwn/openring/tree/master/openring.go

kabwj 7y ago

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

jchw 7y ago

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.

Sir_Cmpwn 7y ago

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.

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