So, uh, why is the go-supported option encouraging me to download it from github at compile time without so much as crude versioning support?

Lots of people run internal Maven repos, they have every dependency vendored, but they also want the ability to choose between versions of that dependency.

Why?

Because you want to have control over all software you're shipping to production.

Sure, but manual vendoring is just one (tedious, error-prone) means to that end. Any sane package manager with something akin to lockfiles gives you the same guarantee without all of the headaches of vendoring (and unvendoring when no longer needed!) all of your transitive dependencies.

It's not tedious or error prone. Just use the tool.s

If "vendoring" precludes one from using a dependency installed on the system, then this practice is static linking all over again. Static linking has its place, but dynamic linking with sane versioning solves many problems.

In the era of containerized application platforms and immutable infrastructure, static linking is the path forward.

People like Go because you have a single executable to drop on a box, no worrying about what version of what libraries are installed. Though, the Go team realizes there is a need for dynamic linked libraries, so they at least have a proposal for it[0].

[0] https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh...

I've been following that proposal, and I'm a bit surprised that it isn't mentioned on the roadmap. Looks like dynamic linked libraries will come sometime in 2.x land?

One of the other talks made reference to it[0].

[0] http://dotgo.sourcegraph.com/post/99652344343/go-team-q-a-de...

I'm pretty sure all Go binaries are statically linked.

Sure, but that's orthogonal to what's being discussed here. You don't check your compiled binary into source control, but proponents of vendoring do check their (transitive) dependencies in.

But they said there are plans for dynamic linking

What problems does dynamic linking with sane versioning solve?