As far as I know, Go statically links the runtime into the binary (including the garbage collector, the scheduling system and more)... so for a small program like this sample, it will appear to be abnormally bloated. If it were a larger, more complex example, then the binary size wouldn't change as drastically (and on a surface level might appear to be more justifiable).
? http://doc.rust-lang.org/std/
> there would likely be multiple json or http libraries (just to name "low-level" libraries with widespread usage)
The standard library used to build json in, that was actually split out to a standalone libraries for various reasons: https://github.com/rust-lang/rustc-serialize
> and you might end up linking a few of them in a binary as indirect dependency.
That's not a counter-argument to erglkjahlkh's comment. In fact it's pretty much irrelevant:
* Go works at a library level, when you import fmt you don't import encoding/json, and it's not loaded
* The issue he outlines is mostly that Go does little to no dead code elimination, when a library is imported all of its content (and the content of its dependencies) will end up in the final library, even if you only access a small utility function
Yet. With the rewrite of the compiler it is safe to assume that there will be many optimizations to come.