I spent an hour this week untangling a build that had gone sideways because two libraries disagreed about which version of a third they wanted. The fix was easy in the end. The hour spent working out why was not, and the whole time a small voice in the back of my head kept saying: this is Go, it is 2018, why am I still doing this by hand.
For the record, dep is fine. It is more than fine. After years of go get pulling whatever happened to be on master and GOPATH being a flat shared space where every project fought over the same checkout, having a tool that writes down what you actually depend on feels like a quiet luxury. Gopkg.toml, Gopkg.lock, a vendor/ directory you can commit and reason about. It does the job.
what dep gets right
The lock file is the headline. You run dep ensure, it solves the constraints, and it writes down exactly which commit of everything ended up in your tree. Check that in and the next person, or the CI box, or you in six months, gets the same build. That alone fixes the worst class of "works on my machine" I used to hit.
constraint
name = "github.com/some/library"
version = "1.2.0"
override
name = "github.com/transitive/thing"
revision = "abc1234"
The override block is the bit I reach for when two dependencies can't agree, which is precisely the mess I was in this week. You force the issue, write down why in a comment, and move on. It is not elegant but it is honest.
what still grates
It is bolted on. dep lives beside the language rather than in it, and you can feel the seam. vendor/ is a directory full of other people's code that you are now responsible for, which is a strange thing to commit but the only way to be sure. The dependency solver is genuinely slow on a big graph; dep ensure on a fresh checkout is a "go and make tea" operation. And it still leans on GOPATH, that one global workspace, so your code has to live in exactly the right directory under exactly the right import path or nothing works. I have lost count of the times I have cloned a repo into the wrong place and spent ten minutes confused before remembering.
None of this is dep's fault. It is doing the best it can without the language's cooperation. But it is the official experiment, the thing the team blessed as the way forward, and it still feels provisional. You can sense everyone is waiting for the real answer.
the hope
What I actually want is for the toolchain to grow this natively. Drop GOPATH, or at least stop making it load-bearing. Let a project declare its dependencies in a file at its root, resolve them reproducibly, and cache them somewhere sensible instead of forcing me to commit a copy of the internet. Make versioning a first-class idea the compiler understands rather than a convention a side-tool enforces.
I have no inside knowledge of when, or whether, that arrives. There has been plenty of mailing-list noise about versioning and the right model for years now, and the Go team move deliberately, which I respect even when it is maddening to wait on. For now dep is the pragmatic choice and I will keep using it. But I will be the first to drop it the day the language ships something better, and I suspect that day is closer than it was. Until then: commit your lock file, write a comment on every override, and put the kettle on before you run ensure.