|Go 2 Details Revealed
|Written by Kay Ewbank
|Monday, 03 December 2018
Details are emerging of what the next version of the Go language will look like, along with concrete information on which of the future changes are going to make it into the next incremental release.
Go is an open source project developed by a team at Google and many contributors from the open source community over more than nine years. The main intended use is as a systems programming language, and it has been used in high profile commercial successes such as Docker.
Some ideas on Go 2 emerged last year at GopherCon 2017, when key Go developer Russ Cox gave a talk on the Future of Go where he laid out ideas for how the next version (informally Go 2) will look. The developers say that the goal for Go 2 is to fix the most significant ways Go fails to scale, bringing along all the existing Go 1 source code. The sort of changes that are being talked over for Go 2 include additional support for error handling, introducing immutable or read-only values, and adding some form of generics.
Go 2 isn't going to appear as a single release, instead interim versions will being including its proposed features, starting with a number in the Go 1.13 release (step 1 in the proposal evaluation process):
The first change will be to add support for General Unicode identifiers based on Unicode TR31. The developers say this addresses an important issue for Go programmers using non-Western alphabets and should have little if any impact on anyone else.
A second change will be support for in number literals, and the addition of binary integer literals. Other languages have these features, and many Go programmers have asked for them to be added to Go, so they've made the list as early as possible.
The final change that will make it into Go 1.13 from the Go 2 list is the ability to have signed integers as shift counts. The developers say that an estimated 38% of all non-constant shifts require an (artificial) uint conversion, and the new ability will get shift expressions better in sync with index expressions and the built-in functions cap and len.
or email your comment to: firstname.lastname@example.org