[creeble]

Simplest explanation I can think of: Static binaries have no dependencies. They should just run and not bark about missing (shared/dynamic) libraries, nor require you to install them.

Of course, even static binaries rely on some basic level of compatibility; typically system-level things that don't change much.

Dynamically-linked binaries have the potential to create a massive dependency graph that can hard or even impossible (for a given o/s installation) to traverse.

[kikoreis]

Those annoying dependency graphs provide both standardized visibility and also the ability to fix and patch components independently of each other.

[tafycent]

Which makes sense for large software systems, but for small tools that you might want to carry around on a flash drive or that you need to always work across multiple machines without having a vm, static binaries make sense.

[adtac]

I'm a big fan of Go's static binaries, but I'm sorry, the last point doesn't make much sense to me. The dependency graph is going to be the same whether or not you include everything in your binary. It just so happens that the Go ecosystem hasn't adopted node's cancerous everything-is-a-dependecy pattern (at least yet). If it did, the dependency graph would be equally horrendous; the only difference is that the dependencies are included in the binary.