In the annual Go user survey, the three top requests made by users for Go version 2 were better package management, error handling and the inclusion of generics. Following these requests, the Go 2 draft designs were shared yesterday to include error handling, error values, and adding generics. Note that these are not official proposals.
The features, error handling and generics are in step 2 according to the Go release cycle, shown as follows.
Source: Go Blog
Yesterday, Google developer Russ Cox, gave a talk on design drafts for Golang 2. Go 2 draft designs were also previewed at Gophercon 2018. In his talk, he mentions that the current boilerplate contains too much code for error checks and that the error reporting is not precise enough. For example, an error while using os.Open in which the name of the file which cannot be opened, isn’t mentioned. As proper error reporting only adds to the code, most programmers don’t really bother with this despite knowing that such a practice may create confusion. The new idea, therefore, aims to add a check expression to shorten the checks while keeping them explicit.
Cox also stresses on adding experience reports. These reports are difficult but necessary to implement new features. Experience reports turn abstract problems into concrete ones and are needed for changes to be implemented in Golang. They serve as a test case for evaluating a proposed solution and its effects on real-life use-cases.
Regarding the inclusion of Generics, Cox mentions: “I’ve been examining generics recently, but I don’t have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can’t answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use cases, we could begin to answer a question like this by examining the significant ones.”
Go 2 is not going to be a single release, but a sequence of releases adding features as and when they are ready. The approach is to first make features backward compatible to Go 1. Minor changes could be seen in Go 1 in a year or so. If there are no backward incompatible changes, Go 1.20 may be just declared as Go 2.
The conversation for Go 2 has started, and there is a call for community help and contribution to converting the drafts into official proposals. Visit the Go page and the GitHub repository for more details.