One of the more irritating aspects of static linking in a C/C++ world is that you have to worry about transitive dependencies because a static library has no way of storing a list of what it depends on. You also have to be careful about the ordering of libraries on the link line. Are these issues somehow solved in Go?

It's interesting to think that dynamic linking may go out of fashion perhaps as more memory means that we don't need it so much. It's certainly more complicated. I've lost count of how many times I've had to explain library version numbers to colleagues. Even if you understand the issues it can be far from trivial to make updates without breaking existing software. The way symbols are bound in a static program is much simpler.

Google statically links everything. Go is developed at Google. Go statically links everything. Coincidence?

As I was thinking about this, it occurred to me that the more popular your static-linked environment is the more that the drawbacks of static linking are a problem.

That's a nice way to restate the reasons static libc was abandoned. libc is very "popular" - everything links against it.

Jeff Sipek.

It turns out that Go was deliberately designed and engineered to solve some of these dependency issues, among other software engineering ones. There's a quite interesting Rob Pike talk and article about this that's we ll worth reading, Go at Google: Language Design in the Service of Software Engineering. Reading between the lines of his article, it seems clear that the Go equivalent of static libraries almost certainly includes information about everything needed to link the static library (including its dependencies).

(In Go, as in many other modern languages, you have to explicitly import packages in order to use things from them. This means that the compiler can completely discover dependencies; it's just a matter of recording them. C's dependency hell for static linking comes from its lack of any such import step; there's only a single global namespace and names in it can magically materialize from anywhere.)

As an application developer, the idea of static linking comforts me because it raises the chances that if someone is going to patch one of my dependencies, they're going to go through a complete compile/test cycle of my application. This should catch any inadvertent incompatibilities introduced by the patch.

(That said, I'm not too familiar with how linking works in C. I'm a java developer, where basically all linking is dynamic. Sometimes people drop in incompatible jar files and then ask me what the scary stacktraces in the logs are all about.)

As a packager (mostly ruby stuff), I find the idea of statically linking everything very interesting. It would make my life much easier (ever tried to properly package chef on RHEL systems? I do...).

One thing I'm not sure though (as I haven't looked into it) is wether Go programs supports some kind of plugin system, say for example if you wanted to develop a daemon that would connect MySQL and/or PostgreSQL and not link to both client libraries.

I don't think that Go currently supports any sort of native dynamically loaded plugin system. At most you might be able to directly load and call non-Go dynamic libraries (although you'd probably need some sort of FFI support) via interfaces to dlopen() and dlsym() and so on.