Version 1.11 of the Go programming language was released over the weekend, just in time for GopherCon 2018, where Google announced the release of draft designs to be potentially implemented in ‘Go 2.’
Since the 1.0 release, Go has strived to maintain stability in the language, and most would argue that it has succeeded, with each subsequent release having less new features that could potentially break compatibility. Keeping in that tradition, version 1.11 doesn’t offer much in the way of exciting new language features. It does, however, introduce an early “Modules” system for dependency management and experimental WebAssembly support. Adding the ability to compile to WebAssembly will allow developers to “compile Go programs to a binary format compatible with four major web browsers” including Google Chrome. Both of these features will need more refinement and will be complete in a future version.
You can read more about these features and many more improvements in the official release notes.
Looking to the future, Google has unveiled three early design drafts at GopherCon to address some of what people consider to be the main flaws of the language, namely Go’s lack of “generics” and its error handling.
Generics support, for the uninitiated, is the ability to write a function that doesn’t need to know what exact types are being put in, and is a hallmark of most modern programming languages. The community has not agreed yet on whether Go truly needs generics, thus this draft design will surely inspire discussion in the Go community.
The other two drafts both have to do with Go’s currently messy handling of errors and error values. Current Go code with error handling has blocks and blocks of code dedicated to that purpose, which can make the code harder to read. One draft was designed to introduce new handling uses a new “check / handle” system to be able to create and reuse error handling blocks, and is actually one of the better solutions I’ve ever seen personally for error handling in programming. The third draft design improves the ability to read errors wrapped in other errors, and format that information both correctly and sensibly.
These designs being shared publicly puts the ball in the community’s court, to discuss and decide if any or all of the improvements should be implemented in the language in the not-too-distant future. One thing that has been stressed is that they would like to maintain full compatibility between Go 1.x and “Go 2” code.