Go in transition: Making sure the move from Go 1 to Go 2 goes smoothly
Incompatible changes are a fact of major updates. But how can we ensure that there are as few as possible in the latest version of Go? A recent proposal from the Go community clarifies several approaches they might take in the language’s evolution into Go 2.
No one likes it when their brand new language update causes major problems with already established code. Unfortunately, it’s something that we really can’t avoid, not even in the lead up to Go 2. Or is it?
A recent proposal from Ian Lance Taylor makes the valid point the community now has the chance to consider changes to the language and standard libraries. Thanks to the healthy debate amongst the Go community, we can basically choose the features we want to continue supporting and maybe decide on what things should break in Go 2.
Although Go promises full backwards compatibility, that’s always something of a reach for many languages under development. Instead, Taylor proposes a slow, gradual transition into Go 2. This way, few developers will be left behind or face drastic incompatibilities.
As a matter of course, developers will have to be aware of any language additions or removals and make sure to utilize the correct language version while developing.
The only way to get around this is to specify a minimum language version in error messaging for unsupported language features. Having a specified maximum and minimum language version lets developers know when and where they are going wrong.
Any language redefinitions are sure to cause an error message or two. It’s important that the community make sure to minimize these kinds of redefinitions. Although Taylor believes that we are mostly stuck with our current semantics, that doesn’t mean we can’t improve things like range issues.
The big transition to Go 2 is a chance to sort through all the standard libraries and see what can be released from the Go 1 compatibility guarantee. After all, whenever you move, you don’t bring everything with. Sometimes you have to do some sorting and see what can be left behind.
Additionally, the big transition is a good time to reevaluate the release cycles for many of these packages. While the 6-month cycle makes sense for some, other might need a faster release schedule. However, creating an ad-hoc release cycle would require a lot of extra work on the part of the package maintainers and testers.
As for the libraries themselves, this is time to evaluate each and decide if they need any changes in the upgrade to Go 2. The core libraries are the packages that are closely tied to the compiler; they should strictly follow the release cycle.
However, the penumbra standard library is maintained independently. It should be possible to use
go get to upgrade or download these packages.
go get should also allow developers to remove packages like index/suffixarray or log/syslog from the releases. That said, a more official depreciation policy is still necessary.
Make your voice heard
Since Go 2 is being debated amongst the community, now’s your chance to make your voice heard. Got an idea or opinion about what direction the language should go? Head on over to the Golang proposal page and get to work!
go 2 work