[simoncion]

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.

[sagichmal]

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

[kyrra]

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...

[23david]

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?

[kyrra]

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

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

[dangerlibrary]

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

[munificent]

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.

[weitzj]

But they said there are plans for dynamic linking

[nulltype]

What problems does dynamic linking with sane versioning solve?