For simple projects or toy apps, gofix is just fine. However, some companies are running complex production systems written in GO 0, and the code may have a lot of dependencies and custom build scripts. In this case it's useful to have an easy way to install and pin Go versions.
Once Go 1 launches, subsequent releases should be compatible with the Go 1, which reduces the need for something like GVM.
> Once Go 1 launches, subsequent releases should be compatible with the Go 1
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...
You can expect the unexpected not to happen all you want, reality won't care a bit.
In fact, this makes me think of the Douglas Adams quote sitting right above my main display:
"The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair"
I wouldn't consider it "necessary" however even the casual Go user can benefit from the automatic environment setup GVM provides. Go is quickly becoming my language of choice and GVM has spared me the hassle of GOROOT and GOPATH setup. Plus I keep anxiously checking `gvm listall` for the Go1 tag
Yeah, I think RVM also kind of proved that build tools that inject themselves via .bashrc are more trouble than they're worth. It was somewhat forgivable with Ruby because they had decades of legacy tools to deal with; one would hope Go would be able to find a better solution.
I am not clear why this is really necessary for GO. Why not just use 'go fix'?