4 ms·

> require no shared libraries One amusing downside: the Golang hello world binary takes 2 MB; when compiled with gcc though (against libgo, therefore, dynamica

> require no shared libraries One amusing downside: the Golang hello world binary takes 2 MB; when compiled with gcc though (against libgo, therefore, dynamically linked), it takes an astonishing 60 KB - not even 64 KB!

brokencode 5y ago
For some applications this matters, but for a typical web server or web architecture, which is what go is optimized for, rarely if ever would a couple MB of binary size make a difference.
- taywrobel 5y ago
  Especially when tossed in a container for most workloads nowadays. You can have a full go binary statically linked and copied into a FROM SCRATCH docker image and it just works, and is miniscule. For example, that's all that the production image of NATS Streaming is - https://github.com/nats-io/nats-streaming-docker/blob/024b04f6c0d4658cf5751b21b48555bbe9280be5/0.22.0/scratch/Dockerfile https://github.com/nats-io/nats-streaming-docker/blob/024b04...
foobiekr 5y ago
... and then someone puts it in a container, probably sourced without any kind of tracking, and blows cross-app shared library page sharing and adds tons of other on-media bloat. It's so crazy where we are.
- bitwize 5y ago
  RAM and storage are cheap. Their cost is a mere pittance for the benefits of containerization. It's like when people whinge about Electron. Electron gets you a runtime that's near identical across the major platforms, with a11y (something the Linux native toolkits still don't have their shit together on) essentially for free, plus you can use modern reactive component frameworks like React and Vue on the desktop. Yeah, I'll pay 300 MiB for that.
  - kaba0 5y ago
    I highly doubt that the optimal GUI development is at “modern reactive comp frameworks”, when decade old desktop frameworks had better tooling than that.
    - EvilEy3 5y ago
      I seriously doubt that. Mobile platforms and web would be moving towards "decade old desktop frameworks" if those were superior.
      - kaba0 5y ago
        Mobile platforms are most definitely not web technology, they are much closer to desktop frameworks. And the only reason the web is not doing so is (was) due to backwards compatibility and HTML being a bad target. But with WASM and canvas-based renderers, desktop frameworks sort of make an appearance on the web (though I personally dislike the canvas-oriented design, which basically throws away every accessibility)
- pjmlp 5y ago
  I find it more ironic when monolithic kernels are argued for and then get placed in layers of abstraction to achieve what microkernels offer out of the box.
simias 5y ago
That used to bother me with Rust as well, but frankly nowadays it's really hard to argue against it. Even in the embedded world you typically have enough flash these days that you're not counting a couple MBs, and as far as RAM is concerned you'd only save some memory if several binaries run simultaneously while linking to the same shared libs. And even then it's not a sure win, because LTO can remove a lot of useless code from dependencies, so if you only use a small part of a dependency you might still be better off with static linking regardless of other factors. It's pretty hard to justify the complexity and overhead of dynamic linking nowadays, IMO.
- pjmlp 5y ago
  Depends, dynamic linking is great for plugins, on the other hand I guess we have learnt that IPC is a better option for security and overall application stability.
- anderskaseorg 5y ago
  Although it used to be worse, these days a standard Rust “Hello, world!” compiles to just 277 KB on Linux with ‘cargo build --release’ and ‘strip’—5× smaller than the equivalent for Go (and there are games you can play to get it down further).
  - simias 5y ago
    Oh, that's very cool, I hadn't checked that in ages. Any idea on what Rust does better here? Better link time optimization? Or is the Go runtime just that heavier?
    - colin_mccabe 5y ago
      Rust doesn't really have a "runtime" in the same sense that Go does. For example, Rust has no GC.
- sitzkrieg 5y ago
  not counting MBs!? must be nice, havent developed on something with 1MB or more in years
slx26 5y ago
No one is actively happy about it, but when you account for garbage collection and other runtime stuff that goes into a regular go program, plus no dynamic linking... you have to be happy with the trade-off. It's the right one for most programs we will ever make.
- throwaway894345 5y ago
  > It's the right one for most programs we will ever make. Unless you’re in the lucrative hello world industry. Or at least I assume it’s lucrative since so many people come here posting about hello world binary sizes—it certainly seems to employ a lot of people.
deleted 5y ago
[deleted]

brokencode 5y ago

For some applications this matters, but for a typical web server or web architecture, which is what go is optimized for, rarely if ever would a couple MB of binary size make a difference.

taywrobel 5y ago
Especially when tossed in a container for most workloads nowadays. You can have a full go binary statically linked and copied into a FROM SCRATCH docker image and it just works, and is miniscule. For example, that's all that the production image of NATS Streaming is - https://github.com/nats-io/nats-streaming-docker/blob/024b04f6c0d4658cf5751b21b48555bbe9280be5/0.22.0/scratch/Dockerfile https://github.com/nats-io/nats-streaming-docker/blob/024b04...

foobiekr 5y ago

... and then someone puts it in a container, probably sourced without any kind of tracking, and blows cross-app shared library page sharing and adds tons of other on-media bloat. It's so crazy where we are.

bitwize 5y ago
RAM and storage are cheap. Their cost is a mere pittance for the benefits of containerization. It's like when people whinge about Electron. Electron gets you a runtime that's near identical across the major platforms, with a11y (something the Linux native toolkits still don't have their shit together on) essentially for free, plus you can use modern reactive component frameworks like React and Vue on the desktop. Yeah, I'll pay 300 MiB for that.
- kaba0 5y ago
  I highly doubt that the optimal GUI development is at “modern reactive comp frameworks”, when decade old desktop frameworks had better tooling than that.
  - EvilEy3 5y ago
    I seriously doubt that. Mobile platforms and web would be moving towards "decade old desktop frameworks" if those were superior.
    - kaba0 5y ago
      Mobile platforms are most definitely not web technology, they are much closer to desktop frameworks. And the only reason the web is not doing so is (was) due to backwards compatibility and HTML being a bad target. But with WASM and canvas-based renderers, desktop frameworks sort of make an appearance on the web (though I personally dislike the canvas-oriented design, which basically throws away every accessibility)
pjmlp 5y ago
I find it more ironic when monolithic kernels are argued for and then get placed in layers of abstraction to achieve what microkernels offer out of the box.

simias 5y ago

That used to bother me with Rust as well, but frankly nowadays it's really hard to argue against it. Even in the embedded world you typically have enough flash these days that you're not counting a couple MBs, and as far as RAM is concerned you'd only save some memory if several binaries run simultaneously while linking to the same shared libs. And even then it's not a sure win, because LTO can remove a lot of useless code from dependencies, so if you only use a small part of a dependency you might still be better off with static linking regardless of other factors. It's pretty hard to justify the complexity and overhead of dynamic linking nowadays, IMO.

pjmlp 5y ago
Depends, dynamic linking is great for plugins, on the other hand I guess we have learnt that IPC is a better option for security and overall application stability.
anderskaseorg 5y ago
Although it used to be worse, these days a standard Rust “Hello, world!” compiles to just 277 KB on Linux with ‘cargo build --release’ and ‘strip’—5× smaller than the equivalent for Go (and there are games you can play to get it down further).
- simias 5y ago
  Oh, that's very cool, I hadn't checked that in ages. Any idea on what Rust does better here? Better link time optimization? Or is the Go runtime just that heavier?
  - colin_mccabe 5y ago
    Rust doesn't really have a "runtime" in the same sense that Go does. For example, Rust has no GC.
sitzkrieg 5y ago
not counting MBs!? must be nice, havent developed on something with 1MB or more in years

slx26 5y ago

No one is actively happy about it, but when you account for garbage collection and other runtime stuff that goes into a regular go program, plus no dynamic linking... you have to be happy with the trade-off. It's the right one for most programs we will ever make.

throwaway894345 5y ago
> It's the right one for most programs we will ever make. Unless you’re in the lucrative hello world industry. Or at least I assume it’s lucrative since so many people come here posting about hello world binary sizes—it certainly seems to employ a lot of people.

deleted 5y ago

[deleted]