Hacker News Reader

Comment by jbooth | Hacker News Reader

Andrew Gerrand: The lack of versioning built into the Go tool incentivizes library authors to provide good, stable APIs.

Are you kidding me??? So if some invariant behavior on an otherwise stable API changes, I don't know until runtime that a bunch of the code that I shipped, haven't changed, and then recompiled a month later has changed it's behavior?

View on HN

If you're shipping serious code you should be vendoring your dependencies.

Why?

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

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.

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

But they said there are plans for dynamic linking

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.

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

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

What problems does dynamic linking with sane versioning solve?

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

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.

Yeah, this seems crazy to me. Also, honestly, while stable APIs can be nice, I would rather have people have the option to change the API in later versions, if it makes things better. But I want to be able to consciously decide to upgrade when I'm ready.

You do have that option. As I explained at the time (but this was not included in the live blog), the convention is to change the import path when the package API changes.

Reply on news.ycombinator.com