I'm so confused by this. Given the context that Go primarily targets, which is daemon services running on server class machines, binary size, so long as it's not totally absurd, is almost completely irrelevant. Is it like a code golf thing? Why do you care?
Given that modern systems include containerization and dozens or hundreds of instances of applications bouncing continually as changes are made or network conditions change, deployment has gotten a lot more “chatty” than tossing a binary on a server and running it.
Reducing binary size makes a difference when the app is deployed to remote servers thousands of times under normal operation.
Storage and bandwidth is cheap, yes, but it adds up.
My company runs Go and Java programs that locally compile in seconds to binaries / JARs that weigh tens of megabytes. But for production, we insist on spending tens of minutes building and copying around Docker containers that weigh gigabytes.
It targets a broader set of items then that (I'd describe as static type, GC, fast to compile / run language?).
I've noticed the issue of big deploy sizes with docker including with interpreted and other big package languages (Java can haul around a ton + JVM etc). It's somewhat hard to get small container sizes even for a simple hello world program with these approaches.
Folks are doing 15MB docker images for Go. Google likes really stripped down things (low attack surface etc) - see their distroless initiative.
These days, server-class machines are often ephemeral and spun up-and-down based on demand. At work, I operate services that have 2 GB of Java code packages, and others that use a single 10 MB Go binary. Guess which one can scale up much more quickly to handle increased demand?
...but the point being made is at 10% reduction, a 9MB and a 10MB binary are indistinguishable.
They scale almost identically.
so... it seems a bit like premature optimisation to devote such a large amount of effort to what appears to be a win that affects virtually no one except those few (FANG) who deploy to thousands of services daily.
I think the fact that binary size has become smaller rather than larger is notable in a world where most other software seems to be increasingly more resource hungry.