4 ms·

There was a big push from the linux distros as the maintainers had anneurisms thinking they'll need to rebuild hundreds of Go applications when/if a big bug is

by NateDad 11y ago

There was a big push from the linux distros as the maintainers had anneurisms thinking they'll need to rebuild hundreds of Go applications when/if a big bug is found in the Go standard library. They also don't like the idea of having N copies of the code for the standard library in N Go applications. Personally, I find that kind of thinking to be a relic of the past when memory and disk space were expensive and compilation took a long time. Sure, if you're running on a raspberry pi, a few megs here and there might actually matter... but even my phone has 2gigs of RAM and 32gigs of disk space.

groks 11y ago
> ...a relic of the past when memory and disk space were expensive ... a few megs here and there might actually matter... The nature of the modern computer is that cpu speed has increased more than memory speed, so if your data doesn't fit into cache your cpu will be do nothing quickly. Even with shared libraries, this phenomena has such an impact that the Linux kernel now has a memory de-duplication feature (mostly for VMs): https://lwn.net/Articles/306704/ https://lwn.net/Articles/306704/
- 4ad 11y ago
  This has NOTHING to do with shared libraries vs. statically-linked code. The size of the binary is completely irrelevant when considering if the code fits in the CPU cache. What's important is the size of code that actually executes. Dynamic linking changes nothing.
  - twoodfin 11y ago
    I'm not sure what you mean. Absent some deduplication wizardry by the OS, if I have 60 processes using the "same" statically linked copy of libfoo, that's 60 copies of libfoo's instructions and static data fighting for cache and real memory. Dynamic linking & decades-old virtual memory technology cull that to a single copy.
mappu 11y ago
The debian snapshot archive is over 30TB. Some single packages take up to 10 hours to build (although all other packages can be built in parallel if you have enough EC2 credit).
- 4ad 11y ago
  I'm not sure if you're complaining about disk space or time spend compiling, but if you're complaining about time spent compiling, the complaint is not valid. Dynamically linked Go programs build just as fast, to a first approximation, as statically-linked counterparts. That's not at all surprising considering that with static linking, each package is also built only once.
sacado2 11y ago
> Personally, I find that kind of thinking to be a relic of the past when memory and disk space were expensive and compilation took a long time. OTOH, it does well with the culture of making a lot of small, specialized executables rather than a single, monolithic application.
- NateDad 11y ago
  Not really? That doesn't seem like it has anything to do with static linking vs. shared libraries. My point was rather that a 3MB executable used to be "large" and now it's not, even if you have 100 of them.

by NateDad 11y ago

groks 11y ago

> ...a relic of the past when memory and disk space were expensive ... a few megs here and there might actually matter... The nature of the modern computer is that cpu speed has increased more than memory speed, so if your data doesn't fit into cache your cpu will be do nothing quickly. Even with shared libraries, this phenomena has such an impact that the Linux kernel now has a memory de-duplication feature (mostly for VMs): https://lwn.net/Articles/306704/ https://lwn.net/Articles/306704/

4ad 11y ago
This has NOTHING to do with shared libraries vs. statically-linked code. The size of the binary is completely irrelevant when considering if the code fits in the CPU cache. What's important is the size of code that actually executes. Dynamic linking changes nothing.
- twoodfin 11y ago
  I'm not sure what you mean. Absent some deduplication wizardry by the OS, if I have 60 processes using the "same" statically linked copy of libfoo, that's 60 copies of libfoo's instructions and static data fighting for cache and real memory. Dynamic linking & decades-old virtual memory technology cull that to a single copy.

mappu 11y ago

The debian snapshot archive is over 30TB. Some single packages take up to 10 hours to build (although all other packages can be built in parallel if you have enough EC2 credit).

4ad 11y ago
I'm not sure if you're complaining about disk space or time spend compiling, but if you're complaining about time spent compiling, the complaint is not valid. Dynamically linked Go programs build just as fast, to a first approximation, as statically-linked counterparts. That's not at all surprising considering that with static linking, each package is also built only once.

sacado2 11y ago

> Personally, I find that kind of thinking to be a relic of the past when memory and disk space were expensive and compilation took a long time. OTOH, it does well with the culture of making a lot of small, specialized executables rather than a single, monolithic application.

NateDad 11y ago
Not really? That doesn't seem like it has anything to do with static linking vs. shared libraries. My point was rather that a 3MB executable used to be "large" and now it's not, even if you have 100 of them.