Out in the open

On the road to Go 2: Goals, constraints and roadmap

Gabriela Motroc
Go 2

© Shutterstock / Osborn

If you’re not at GopherCon but you’d still like to know what Russ Cox said during his talk, you’ll be happy to know that the text of his talk has been uploaded on the Go blog. Read on to find out what’s cooking in the Go kitchen and how you can help them at every step along the way.

GopherCon 2017 is in full swing. The schedule is packed and the participants are satisfied (check #gophercon and you’ll see for yourself) but the real news is Go 2 — it’s not here yet but it’s the first glimpse we gain of how it’s going to look like.

Go 2: Goals, constraints, limitations, roadmap

If you’re not at GopherCon but you’d still like to know what Russ Cox said during his talk, you’ll be happy to know that the text of his talk has been uploaded on the Go blog.

Now we have five years of experience using Go to build large, production-quality systems. We have developed a sense of what works and what does not. Now it is time to begin the next step in Go’s evolution and growth, to plan the future of Go. I’m here today to ask all of you in the Go community, whether you’re in the audience at GopherCon or watching on video or reading the Go blog later today, to work with us as we plan and implement Go 2.

Cox explained that even a small startup “may use large cloud-based API services provided by other companies and use more open-source software than software they write themselves. Production scale and development scale are just as relevant at that startup as they are at Google.” As a result, the goal for Go 2 is “to fix the most significant ways Go fails to scale.”

Although the goals have not changed much since the beginning (they still want to make programmers more effective at managing two kinds of scale: production scale and development scale), constraints are a whole different story. According to Cox, the most important constraint is existing Go usage (see tweets above).

We estimate that there are at least half a million Go developers worldwide, which means there are millions of Go source files and at least a billion of lines of Go code. Those programmers and that source code represent Go’s success, but they are also the main constraint on Go 2.

One of the issues (in addition to asking developers to “unlearn old habits and learn new ones only when the reward is great”) is that version 2 needs to carry all the existing Go 1 source code. Cox revealed that “mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years.” In short, “we must not split the Go ecosystem.”

Go fix (automated tooling) will definitely be part of the solution, he claimed.

To minimize disruption, each change will require careful thought, planning, and tooling, which in turn limits the number of changes we can make. Maybe we can do two or three, certainly not more than five.

I’m not counting minor housekeeping changes like maybe allowing identifiers in more spoken languages or adding binary integer literals. Minor changes like these are also important, but they are easier to get right. I’m focusing today on possible major changes, such as additional support for error handling, or introducing immutable or read-only values, or adding some form of generics, or other important topics not yet suggested. We can do only a few of those major changes. We will have to choose carefully.

SEE ALSO: What to expect from Go 1.9

How will they ship and deliver Go 2?

According to Cox, the idea is to ship the backwards-compatible parts of Go 2 incrementally, feature by feature, as part of the Go 1 release sequence. Let’s have a look at a handful of important properties:

  • It keeps the Go 1 releases on the usual schedule
  • It avoids splitting development effort between Go 1 and Go 2
  • It avoids divergence between Go 1 and Go 2 (migration headaches)
  • It allows the team to focus on and deliver one change at a time (that’s one way to maintain quality)
  • It will encourage them to design features to be backwards-compatible.


We might start seeing minor changes about a year from now, for Go 1.12 or so. That also gives us time to land package management support first. Once all the backwards-compatible work is done, say in Go 1.20, then we can make the backwards-incompatible changes in Go 2.0. If there turn out to be no backwards-incompatible changes, maybe we just declare that Go 1.20 is Go 2.0. Either way, at that point we will transition from working on the Go 1.X release sequence to working on the Go 2.X sequence, perhaps with an extended support window for the final Go 1.X release.

Although these are just estimations, there’s something to look forward to. Keep in mind that the team is not abandoning Go 1 — they promised to “bring it along to the greatest extent possible.”

Go developers, unite!

Go needs your help. Although the Go 2 conversation is out in the open, it will take more than a discussion to make it happen. Cox emphasized the need for experience reports and encouraged developers to tell them what’s working and what’s not working for them.

Write a blog post, include real examples, concrete detail, and real experience. And link it on our wiki page. That’s how we’ll start talking about what we, the Go community, might want to change about Go.

You heard the man, now let’s help make Go 2 great!



Gabriela Motroc
Gabriela Motroc is an online editor for Before working at S&S Media she studied International Communication Management at The Hague University of Applied Sciences.

comments powered by Disqus