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.

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.

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.

That's not a reasoned point then.

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.

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.

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.