Go binaries start at around 2mb on my machine, so not as bad as 5mb, but still much bigger than similar utils in c. Storage is getting dramatically cheaper all the time though, so the size is becoming less important.
Shared libraries for the std lib would definitely be nice for utils, but they do have drawbacks too (dll-hell).
The problem is not in storing the binary, the problem is that you have to load the binary in memory to execute it. So 5mb you have to transfer from disk to memory and keep it there until you're done (and this is not even counting the runtime memory use)
Not true at all on systems that use on-demand paging (i.e. all systems in the past 30 years). Only what's used is paged-in, and it's paged-in only when it's used. A big part of Go binaries are DWARF info, which are not paged-in in regular operation. Also, much of the code is not paged-in either. The code is currently bloated because the linker can't always statically determine which methods it can elide (it does that for functions), because Go allows to query the dynamic type of an interface at runtime (reflection, type switches and type assertions, and all that). Alan Donovan has done some promising static analysis work that will allow the linkers to elide more code than they do now.
If memory use is a huge issue, you can get down to 400KB or so without using the stdlib - just copy in the isolated code you need if your tool actually requires it. Even with liberal use of the stdlib it's not 5MB on average, more like 1-2MB - where did that 5MB figure come from? It is possible to have smaller binaries with static linking but you have to be careful. Of course it'd be nicer if they were more the size of tiny linux utils (30KB), but they'd need dynamic linking for that, which brings up other issues.
If you are severely resource constrained, and need to have lots of tiny programs resident in memory at once, then go with static linking is not a good choice, but does this preclude using go tools on modern servers, desktops, phones where many binaries are typically > 1MB today and many are only run for short periods anyway?
> Shared libraries for the std lib would definitely be nice for utils, but they do have drawbacks too (dll-hell).
There is also .a/.lib hell, the only difference is when it gets handled.
In Windows dll-hell is a solved problem since Windows 2000 for any developer that bothers to follow Microsoft guidelines instead of copying dlls into systems directories.
I didn't mean by referencing dlls to imply this was a windows-only problem, just that using dynamically linked libraries shifts the burden of dealing with dependency conflicts to the runtime machine, and away from the developer at compile time.
Shared libraries for the std lib would definitely be nice for utils, but they do have drawbacks too (dll-hell).