Sorry, Go 2 probably won’t add your ‘missing’ feature

The official Go blog has provided the first concrete details about the next version of Google’s Go language, which is used to create popular applications like Docker and Kubernetes, as well as to incrementally replace critical internet infrastructure.

But Go developers waiting for immediate word about generics, or other pet features they’ve long been waiting to see added to the language, are going to walk away disappointed.

The post, written by Go architect Russ Cox, details how the chief goal for Go 2 is “to fix the most significant ways Go fails to scale.” By “scale,” Cox is referring to both production and development. The former is about “concurrent systems interacting with many other servers, exemplified today by cloud software,” and the latter is about “large codebases worked on by many engineers coordinating only loosely, exemplified today by modern open-source development.”

Part of meeting the second goal, scaling to large teams, involves ensuring that existing Go developers and codebases are not left behind. “Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa,” wrote Cox, “must work effortlessly during a transition period of multiple years. We’ll have to figure out exactly how to do that; automated tooling like go fix will certainly play a part.”

Other languages have experienced major growing pains between revisions when they introduced changes that weren’t wholly backwards compatible. For example, Python 2 and Python 3 have essentially the same syntax, but enough differences to form a major rift between the two versions of the language.

One possible feature, generics, has been a wish-list item of some Go developers, who claim it will make certain programming tasks simpler. But the Go team has consistently expressed reluctance to include generics, because introducing it might complicate the language in ways its designers want to avoid.

Cox mentioned generics directly in the blog post, but framed the discussion around them in terms of how any new language feature needed to have a concrete use case attached to it. In his view, any such addition needs to be driven by specific real-world scenarios—what Cox called experience reports.

“I don’t have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve,” Cox wrote. “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.”

Roughly three camps have developed in the Go community around the question of generics. Some believe the language doesn’t actually need them, because existing language features handle many of the same use cases. Others have amassed various workarounds, mostly by way of Go features such as interfaces. But a third contingent insists that adding generics would make it far easier to work with a whole class of problems in Go.

The Go team’s stated plan is to avoid schisms in the language because of such profound changes, and to only introduce such things “when the reward is great.” Such goals complement Go’s standing as a language for building infrastructure that’s sustainable and maintainable, with code that’s still readable and usable decades down the line. But that also means the vision for the language from its creators frequently supersedes the demands made on it by its users.