Go language Next: Russ Cox talk go 2 planning

This is a creation in Article, where the information may have evolved or changed.

On July 13, Russ Cox shared "The Future of Go" on Gophercon, reviewing the history of the go language and looking forward to go 2.

Rob Pike, Robert Griesemer and Ken Thompson discussed a new programming language for a while, and on September 25, 2007, Rob suggested that it be named Go.

Later, Russ Cox and Lance Taylor joined the Go language design team. With 5 of them, they developed two compilers and a standard library, laying the groundwork for the Go language to be released in open source for November 10, 2009.

For the next two years, with the help of the open source community, the Go language has introduced a lot of big and small changes. Almost every week there are some incompatible changes, and the programs you develop with Go need to be constantly updated. This hinders further adoption of the Go language. This also prompted the development team to focus on the compatibility guarantee for Go 1.

March 28, 2012, Go 1 officially released.

After the release of Go 1, the development team is more focused on not changing the language, but using Go in their own projects, and constantly improving the implementation. They migrated go to many new systems, almost rewriting all the performance-sensitive areas, making go run more efficient, and developing a number of important tools (such as race detector).

Now that the development team has 5 years of experience using go to build large-scale, product-level systems from go 1, it's time to consider the next step in the evolution and growth of go.

Go 2 put on the agenda.

Russ hopes to implement Go 2 together with the help of the community.

Goal

Go today's goal and ten years ago there is no two: scale (large).

Allow programmers to manage two types of scale issues more efficiently: one is the scale of the product, especially the concurrent systems that want to interact with many servers, such as cloud software, and the scale of development, especially large-scale code libraries written by a large number of loosely-collaborating engineers, such as modern open source software.

The goal of Go 2 is to solve the bad things that go 1 does in scale.

Constraints

There are already a lot of go language developers, there are a lot of go code, a wide range of applications, are bound to Go.

According to Russ estimates, there are at least 500,000 Go developers around the world (see the estimated way: Https://research.swtch.com/gophercount).

Go 2 must consider these developers. Only when the rewards are huge can they give up their old habits and learn new ways to use them.

Go 2 must accept the existing Go 1 source code. The development team does not want to fragment the Go ecosystem. (The Python Community's lesson) during a fairly long transition period, the Go 2 import package for go 1, or go 1 to import the Go 2 package, should be easier to do, which requires some automated tools.

In order to minimize disruption, each change must be considered, which in turn limits the number of changes that can be introduced. Maybe you can do two or three, but not more than five.

Russ also briefly mentions some of the possible changes:

I ' m focusing today on possible major changes, such as additional support for error handling, or introducing immutable or R Ead-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'll have to choose carefully.

It mentions the generics that most people talk about.

Process

Russ introduced the Go development process.

Before the open source, the design team of several people in the office next to each other, gathered to chat, a picture on the whiteboard, back to the discussion of the content of the implementation of the good. Have a question to come back to discuss.

But in a community of today, the previous model has not been feasible.

He summed up the current pattern as follows.

One is to use Go to accumulate experience.

The second is to find the problem that may need to be solved and express it clearly, explain it to other people, and write it down finally.

Three is to provide solutions for the problem, and others to discuss, and based on the discussion to improve the program.

Four is to implement the program, evaluate, based on assessment improvements.

Finally, deliver the solution and add it to the language, class library, or tool that the developer uses every day.

iterative, continuous iteration.

How go 2 will be delivered

If the features to be added to go 2 are divided into compatible and incompatible parts, Russ mentioned the following ideas.

(1) In accordance with the release plan of Go 1, incremental delivery of compatible parts, a feature of a feature to add in. This has several advantages:

• Keep Go 1 released at normal pace, fix bugs in a timely manner, and bring improvements that users depend on.

• Avoid spreading the power of development to go 1 and go 2.

• Avoid differences in go 1 and go 2 to simplify migration.

• Focus on each delivery of a change to ensure quality.

• Encourage teams to design backward-compatible features.

(2) Consider the incompatible part again.

Once all backwards-compatible work is done, such as the Go 1.20 version, you can develop the incompatible part of Go 2.0 on this basis. If it turns out that there is no such change, you might just name go 1.20 as Go 2.0 (the friends who are familiar with Java are not unfamiliar with this strategy, Java 1.5 = "Java 5"). In any case, the development work will move from Go 1.X release sequence to go 2.X sequence.

See Russ example version number--1.20, heart a tight, now is the development of the version is 1.9, 9 to 20, the finger count not come over AH.

The specific plan for Go 2, followed by a lot of discussion in the development team and the community, let's look forward to it together.

By the way, the reading of Go 2 also makes the programmers ' jokes very exciting.

Resources:

1.Toward Go 2

2.The Future of Go