4 ms·

Yeah, what an outrage this is. 1.3 megabytes. That's like $0.00004 USD worth of hard drive space. Does the go team think we are all rich or something?

SBullet01 12y ago
I think the point he tried to make was that if only "hello world" produces a 1.3 megabytes executable, the file size of a fairly complicated program made in Go will be significantly larger than the same program implemented in another language.
- enneff 12y ago
  Which makes no sense, anyway. The reason a Hello World program in Go is large is because it must include the baseline runtime support that is included in any Go program. A 10 line program won't be 13mb.
- hueving 12y ago
  That's like trying to predict the cost of a flight by cost per mile using a quote from SFO to SJC as a baseline.
- nutate 12y ago
  That's not a reasoned point then.
- falcolas 12y ago
  You're right - it will be significantly larger. But then again, it doesn't depend on your system having all of the necessary libraries of the correct version and the overhead of dynamic linking. It's a tradeoff, and worth it in my opinion.
- danieldk 12y ago
  A dependency parser (in other words, serious program) in Go, linking in some external dependencies and a C++ machine learning library (statically): % du -k eval/eval 2040 eval/eval % strip eval/eval % du -k eval/eval 1864 eval/eval Don't just assume. Measure.
- dvirsky 12y ago
  I'm looking at an executable of a medium program I'm working on, probably around 5k LOC of my own code, using tons of standard library modules and linking to probably another 10-20k LOC of 3rd party libraries, all debug symbols in place. Weighs 5MB. I don't think this program in C++ would weigh much less. Anyway it can be improved, but to me there are far more important things to be improved about Go than the binary size of small programs.
slyall 12y ago
Plenty of CPUs out there with cache sizes smaller than that, or other things running on the machine that would also like to use the cache.
- 4ad 12y ago
  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. Go binaries have huge DWARF tables, and a lot of the code is dead code. The code that actually executes is not bloated. It's not the most efficient code in the world, because the compilers don't have an optimizer as advanced as gcc's, but it's not unreasonably large.

SBullet01 12y ago

I think the point he tried to make was that if only "hello world" produces a 1.3 megabytes executable, the file size of a fairly complicated program made in Go will be significantly larger than the same program implemented in another language.

enneff 12y ago
Which makes no sense, anyway. The reason a Hello World program in Go is large is because it must include the baseline runtime support that is included in any Go program. A 10 line program won't be 13mb.
hueving 12y ago
That's like trying to predict the cost of a flight by cost per mile using a quote from SFO to SJC as a baseline.
nutate 12y ago
That's not a reasoned point then.
falcolas 12y ago
You're right - it will be significantly larger. But then again, it doesn't depend on your system having all of the necessary libraries of the correct version and the overhead of dynamic linking. It's a tradeoff, and worth it in my opinion.
danieldk 12y ago
A dependency parser (in other words, serious program) in Go, linking in some external dependencies and a C++ machine learning library (statically): % du -k eval/eval 2040 eval/eval % strip eval/eval % du -k eval/eval 1864 eval/eval Don't just assume. Measure.
dvirsky 12y ago
I'm looking at an executable of a medium program I'm working on, probably around 5k LOC of my own code, using tons of standard library modules and linking to probably another 10-20k LOC of 3rd party libraries, all debug symbols in place. Weighs 5MB. I don't think this program in C++ would weigh much less. Anyway it can be improved, but to me there are far more important things to be improved about Go than the binary size of small programs.

slyall 12y ago

Plenty of CPUs out there with cache sizes smaller than that, or other things running on the machine that would also like to use the cache.

4ad 12y ago
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. Go binaries have huge DWARF tables, and a lot of the code is dead code. The code that actually executes is not bloated. It's not the most efficient code in the world, because the compilers don't have an optimizer as advanced as gcc's, but it's not unreasonably large.