A thought about static linking and popularity
This all started with my entry that touched on packaging with Go. Go is attractive partly because it what you get at the end is a basically self-contained program with no dependencies (unlike in, say, interpreted languages). One part of this is that Go static-links everything.
The major advantage of static linking is no runtime dependencies. The disadvantages of static linking are that updates to packages (in the Go sense, ie a component or a library) are more of a pain, that the accumulated collection of everything using a package takes up more disk space, and that that a bunch of things running at the same time that use the same package can't share its memory (each gets its own copy).
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. If you only have a few programs written in Go, it's not a particularly big issue to rebuild and reinstall things if (or when) a bug or security issue comes up, and you wouldn't save much disk space or memory anyways. But imagine if Go becomes a popular language for writing programs in, to the point where a typical Linux system has a couple of hundred static-linked Go programs; all of these drawbacks would be much larger. A bugfix to a core package would result in a huge update, for example, because many programs use it and would have to be rebuilt.
(I suspect that the authors of Go don't really care about it being popular in this way and don't expect anything like it to happen any time soon, so I doubt that this issue is something that even crosses their radar.)
Another way to put this is that most of the time, static versus dynamic linking is a system engineering issue instead of a language or a programming one. The system administrators and system builders want it, while programmers don't care (except as a neat technical challenge).
(There are uses for being able to dynamically load code, even just at startup, but many programs don't need anything like that. Even when they do, these days things like embeddable JIT'd 'interpreted' languages may offer alternate solutions.)