One of the things coming in Go 1.11 is (experimental) support for 'vgo' package versioning; you can read some (in-progress) documentation here and here. One of the reasons I'm looking forward to projects adopting it is that it holds great promise for cleaning up my $HOME/go/src tree.

The problem with my $HOME/go/src currently is that it mingles together programs (and sometimes packages) that I'm actively using and tracking along with their various, assorted, and ever-changing dependencies. I care about the programs but not the dependencies, but with them co-mingled it's hard to keep either straight and thus hard to notice and clean up when a dependency is no longer needed. I generally only notice when I spot pending updates that are still there even after I 'go get -u' all of the actual programs I'm using. In a 'vgo' world, the dependencies will get downloaded and stored in a separate area from the actual packages I'm building; I can purge that area every so often if I want to.

(Of course doing this purge is slightly risky, since a dependency might have removed its canonical master version. It would be nice if Go would track what dependencies in my cache are needed by what (and how recently), but I don't really expect that to happen.)

I was going to say something about how the new module aware behavior of 'go get' is not ideal for my case, but now that I read the documentation I'm not sure of that because I'm not sure I understand how using 'go get' to just fetch and build a program is supposed to work now. I suspect that there's going to be some behavior changes as people talk to the Go developers (and I also rather suspect that the Go developers will find broad objections to getting rid of support for things without go.mod files). In any case it looks like I won't be able to make any sort of near term transition; this is instead going to be a long term kind of thing.

(Modules would directly help us with something at work, except that we're going to be on Go 1.10 for years to come because that's what Ubuntu 18.04 comes with.)

(I've sort of written about the clutter issue before in this entry.)

Sidebar: How I want a module-aware 'go get' to behave

Basically I want a mode where Go prefers being module enabled if there's a go.mod available but falls back to the current behavior if there isn't. For 'go get', this would mean downloading the package to $GOPATH/src as it does today (because there's no other good place to put it), then either getting its dependencies as modules (when it has a go.mod) or fetching them into $GOPATH/src as today (if there's no go.mod), then building using the appropriate bits (either module aware or not). This would provide an essentially transparent upgrade path as Go programs that I build start migrating to using Go modules and having a go.mod.

(Right now it's not clear to me how you're supposed to correctly fetch and build a Go program that uses go.mod.)