Nine years after the inception of Go, five of it under the 1.x banner, Go 2 has started taking shape under the watchful eyes of its large community.

A bit more than 120 proposals for the next major release have been filed, and now it’s time to find out what will actually make the cut. This is something that can’t be taken lightly, since many suggestions seem backward incompatible and large parts of today’s popular ecosystems (e.g. container-related technologies) count on the language’s stability.

In a blog post on the state of things, Robert Griesemer, who is one of the initial language designers, described the situation like this: “We are constrained by the fact that we now have millions of Go programmers and a large body of Go code, and we need to bring it all along, lest we risk a split ecosystem. That means we cannot make many changes, and the changes we are going to make need to be chosen carefully.”

To keep the ever-growing ecosystem involved in making those choices and keep moving Go forward, the core team has come up with a proposal evaluation process, that Griesemer outlined on the Go blog. Roughly parallel to a release cycle, the Go team will select a small number of Go 2 proposals, that “address an important issue for many people, have minimal impact on everybody else, and come with a clear and well-understood solution. […] As a rule of thumb, we should aim to help at least ten times as many developers as we hurt with a given change.”

Once the team has identified fitting proposals, it will announce the selected items, and collect concerns and suggestions from the community. This feedback will then be used as the foundation for the implementation of the proposal, which is aimed to be finished on the first day of the next release cycle. During this cycle, team and community will have a chance to experiment with the new addition and give further feedback.

In time with the three month repository freeze before a release, the Go team takes the collected information into account and decides whether the changes made should be shipped with the next version. If the decision is negative, the proposal may be reworked or declined for good.

To get the process going and see if it works as planned, the team has decided on three backward-compatible language proposals for the Go 1.13 release. “As the process is used we will discover the ways in which it fails to work well and we will refine it as needed. The critical part is that until we use it in practice we won’t know how to improve it.”

Therefore, “General Unicode identifiers based on Unicode TR31”, “Binary integer literals and support for _in number literals” and “Permit signed integers as shift counts” are now up for comments. While the second may not really solve an important issue, it seems to be a popular request which would get the language up to par with others. General unicode identifiers would solve issues for developers using non-western alphabets and shouldn’t have much impact on anyone beyond that group, while the permitting of signed integers as shift counts could help making code cleaner.

The community is called upon to give their feedback via the GitHub issues of the proposals mentioned. Clearly approved features will be implemented during the development cycle planned to start in early February and users will have the chance to add feedback until the code freeze around May 1, 2019. Whether or not the implementations will land in the next release, will be decided by the Go team shortly after.