Go in transition: Making sure the move from Go 1 to Go 2 goes smoothly

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.

Language changes

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.

SEE ALSO: Meet zygomys — An embedded scripting language for Go

Library changes

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.

SEE ALSO: Go 2 error handling will bring a new errors idiom to the language

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

The post Go in transition: Making sure the move from Go 1 to Go 2 goes smoothly appeared first on JAXenter.