[georgemcbay]

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?

[slyall]

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]

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]

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]

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]

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.

[dvirsky]

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.

[microtonal]

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.

[falcolas]

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.

[nutate]

That's not a reasoned point then.