And besides, in a very short time, Go is going to commit to API stability with Go 1. And given that, and static typing (even at runtime), and Go's beautiful module system, and the fact that static linking is the norm, all means that worrying about which Go version you are running on is a silly concern.
This tool purports to solve dependency hell, but dependency hell, especially in a language with no stable ABI where everything is compiled from source, is entirely about package management. Go's standard library used to be in flux, which made pinning a version an important piece of ensuring source compatibility with packages. That's about to go away, and I hope GVM-like tools will follow.
1. cross-platform.
2. allows users access to the latest version of the software immediately.
3. allows installation of multiple versions. API/ABI stability is great but perfect backward compatibility is never possible. E.g. some apps actually rely on bugs in the platform and if you fix them they break; yeah yeah I know the software must be fixed but there may be a ton of reasons why that doesn't happen or at least not happen immediately and there's a clear need among users to be able to install multiple versions of a platform/library.
RPM/DEB theoretically support (2), but in practice distros never do that. Third party packagers that immediately provide the latest versions are most exception to the rule because they need to replicate their effort multiple times over multiple platforms thanks to the lack of support for (1). RPM/DEB don't even try to support (3).
* Cross-platform.
* Easy access to remote packages as soon as they're posted.
* Versions must specified, so builds are very repeatable. You bear the responsibility of updating your dependencies, but you don't get surprised if a version decides to break compatibility, either.
Also, very decentralized, and it's easy to create a directory locally to hold the dependencies within a project (specify a file:// repository relative to ${project.dir}), or on a per-system-user level (mvn install), or on a per-company/organizational unit basis (self-hosted repos are a cinch).
It's actually a fantastic package management system tailored to Java that works extremely well. Its main problem is that it's also fantastically verbose, and including more and more build plugins can grow exponentially more arcane the greater the number of plugins involved. However, with Go's standardized directory layout among other things (I admit, I haven't done much research into trying Go out), something akin to Maven may actually be a good fit.
As far as the development environment is concerned, I find it easy to manage multiple versions of Go by setting $PATH and $GOPATH as needed. I only work with a couple of versions of Go at a time and I don't share packages between versions of Go, so my situation might be simpler than what they have at moovweb.
I expect that I will mostly use a single version of Go after Go 1 is released next week.
I am not clear why this is really necessary for GO. Why not just use 'go fix'?
Once Go 1 launches, subsequent releases should be compatible with the Go 1, which reduces the need for something like GVM.
Which does not mean that they will be, despite Sun's effort to never formally deprecate (let alone remove) anything and the glacial pace of the language, there have been backwards compatibility issues in the past: reliance on implementation details or under-specified behavior which got changed, reliance on bona-fide bugs which just happened to do what a developer wanted in that case, etc...
