>By default, Go does dynamically link to some things--it will prefer to use the system DNS resolver if one is available, for example. But you can disable this by setting `CGO_ENABLED=0` at compile time. If you do this, a Go program needs nothing more than a linux kernel (no system libraries or even libc) and whatever other files it requires (certificates, for SSL for example).
Ah, sounds similar to what it says in the osso.nl link I posted below. Good to know.
>I'm sure you can make statically-linked C programs which are smaller. For example, the musl libc implementation is quite small and designed for static linkage. But lots of libraries break (often in bizarre and hard-to-debug ways) if they don't link against glibc specifically, so it's not a panacea.
Didn't know this, interesting. But actually, I didn't mean making statically-linked C programs smaller by using leaner libraries like musl. I just meant that for equivalent code, the resulting C binary (even when using the default libc) was smaller by a lot than the Go binary. And so were the Free Pascal and D binaries smaller than the Go binary, but they were both slightly larger than the C binary. But it was only an anecdotal observation based on writing a few small programs in C, Go, Free Pascal, and D, and comparing the resulting binary sizes. Not a thorough scientific study.
>Agreed, but again, Go does allow for dynamic linkage in those cases so you can conserve disk space.
Got it.
>>There's no doubt that if you're golfing, C allows for smaller binaries than Go, but Go can meet 99.9% of real-world requirements when it comes to size (if you're at the extreme end of what Go can support, you've probably already ruled out Go for other reasons).
It wasn't about golfing, it was about equivalent code in the two languages, and the relative sizes of the resulting binaries. But good last point (about 'other reasons').
>There are still many reasons to pick other languages besides Go--if you're working on a hard real-time system, if you're working with a team of people who all prefer a different language, if you're working in a domain (iOS app dev, for example) for which there are no good Go libraries, if you're willing to trade all else for extreme performance or extreme correctness, etc. But Go is actually a pretty good little language for most things that aren't at those extremes.
Agreed. In that sense it is somewhat like Python, which is sometimes described as "the second-best language for almost any domain", an interesting description that I read only somewhat recently. I wouldn't necessarily fully agree with that description, it is probably the best language or at least equally the best (with some other language) for certain areas. Similarly, there are probably areas where Go is, if not the best language, one of the best, for certain kinds of tasks, such as the command-line utilities, web and network server applications that it is often used for.