[marketer]

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.

[masklinn]

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

[wglb]

I am getting that the GoFolk are building GOLANG with this problem firmly in mind, and may just be expecting to avoid it.

[masklinn]

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"