On July 13, Russ Cox shared The Future of Go at GopherCon, looking back at The history of Go and looking ahead to Go 2.

Rob Pike, Robert Griesemer, and Ken Thompson had been discussing a new programming language for some time, and on September 25, 2007, Rob suggested it be called Go.

Later, Russ Cox and Lance Taylor joined the Go design team. Together, the five developed two compilers and a standard library, paving the way for the open source release of Go on November 10, 2009.

Over the next two years, with the help of the open source community, Go introduced many changes, big and small. There are incompatible changes almost every week, and programs developed with Go need to be updated constantly. This prevents further adoption of Go. This prompted the development team to focus on compatibility guarantees for Go 1.

On March 28, 2012, Go 1 was officially released.

 

After Go 1 was released, the development team’s focus was less on changing the language and more on using Go in their own projects and improving the implementation. They ported Go to many new systems, rewrote almost everything performance-sensitive to make Go run more efficiently, and developed many important tools (such as Race Detector).

Now that the development team has five years of experience building large-scale, production-level systems with Go since the Go 1 release, it is time to consider the next evolution and growth of Go.

Go 2 is on the agenda.

Russ hopes to make Go 2 a reality together with the help of the community.

The target

Go’s goal today is the same as it was ten years ago: Scale.

Allowing programmers to more efficiently manage two types of scaling problems: scaling of products, especially concurrent systems that interact with many servers, such as cloud software; One is the scale of development, especially large code bases written by large numbers of loosely collaborating engineers, such as modern open source software.

The goal of Go 2 is to address the scale problems of Go 1.

The constraint

At present, there are a large number of Go language developers, a large number of Go code, a wide range of applications, are constraints on Go.

According to Russ estimation, now Go developers around the world at least 500000 (estimate see: https://research.swtch.com/gophercount).

Go 2 must consider these developers. Only if the payoff is huge can they abandon old habits and learn new ones.

Go 2 must accept the existing Go 1 source code. The development team did not want to disrupt the Go ecosystem. Go 2 importing Go 1 packages, or Go 1 importing Go 2 packages, should be relatively easy to do over a fairly long transition period, requiring some automated tools.

Each change has to be considered to keep disruption to a minimum, which limits how many changes can be introduced. Maybe two or three, but no more than five.

Russ also outlined some possible changes:

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.

One of the most discussed generics was mentioned.

process

Russ described the development process of Go.

Before open source, a few people from the design team would sit next to each other in their offices, talk, draw on a whiteboard, and then go back and implement what was discussed. Come back if you have any questions.

But in today’s community, that model no longer works.

He summed up the current model as follows.

One is to use Go to accumulate experience.

The second is to identify problems that may need to be addressed, express them clearly, explain them to others, and finally write them down.

Third, provide solutions to problems, discuss with others, and improve solutions based on discussion.

Four is to implement the program, evaluation, based on evaluation improvement.

Finally, deliver the schema and add it to the language, class library, or tools that developers use everyday.

The cycle repeats itself.

How will Go 2 be delivered

If you break down the features to be added to Go 2 into compatible and incompatible features, Russ offers the following ideas.

(1) According to the Go 1 release plan, the compatible parts should be delivered incrementally and added feature by feature. This has several advantages:

  • Keep Go 1 on track, fix bugs, and deliver improvements that users can rely on.

  • Avoid spreading development effort between Go 1 and Go 2.

  • Avoid divergence between Go 1 and Go 2 and simplify migration.

  • Focus on delivering one change at a time to ensure quality.

  • Encourage teams to design backward compatible features.

(2) Consider the incompatible part again.

Once all the backward compatibility work is done, say Go 1.20, you can build on that to develop incompatible parts of Go 2.0. If it turns out that there are no such changes, we might just call Go 1.20 Go 2.0 (Java 1.5 = Java 5). Either way, development will move from the Go 1.x release sequence to the Go 2.x sequence.

Russ’s example of version numbers — 1.20 — was a bit of a surprise. There are currently versions 1.9 in development, 9 through 20, and I can’t count them on my fingers.

There will be a lot of discussions between the development team and the community about the specific plans for Go 2, so let’s see.

By the way, the Go 2 pronunciations also make programmers very excited.

References:

1.Toward Go 2  https://blog.golang.org/toward-go2

2. The Future of Go https://about.sourcegraph.com/go/the-future-of-go