The future of Go, Russ Cox

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

Go history

On September, together with Rob Pike, they decided on the name. Go.

On November, Go is open sourced.

Go 1, the first stable release, was released on March 28, 2012.

Before go 1, go was broken every week. Programs had to being updated weekly to continue to work. This is blocking larger adoption. That is motivation for the Go 1 guarantee.

Since then, the language had been improved internally. The performance was improved, better tooling like the race detector was added.

Go 2

Today, Russ asks in implementing Go 2.

Next up, this talk would cover the following aspects of Go 2:

• Goals
• Constraints
• Limitations
• Importance of writing about experiences of using Go
• How we ' ll deliver Go 2
• And how we (the community) can help

Go ' s largest goal is scale. We want to make programmers more effective managing:

• Scale of their system and its deployment
• Scale of CODEBASE and its development

The goal for Go 2 are to fix the most important ways in which Go 1 fails to scale.

Go 2 ' s largest constraint is existing usage.

There is 500k+ go developers, millions of Go source files, 1+ billion of go source lines.

Go 2 must bring all the developers along with it. Unlearning of certain practices must is done. So, it must is worth it to them.

Go 2 must also bring all the existing code, we must not fragment the ecosystem.

We'll have the to-figure out how-to-do. Automated tooling like go fix would play a part.

What can we do? Maybe three major changes. Plus minor housekeeping changes. More details for be determined.

We can only do a few major changes. Doing more than this means that upgrading would be too difficult and creates the risk of people staying back. That means we'll have to choose the major changes very carefully.

Process for developing Go

What's the process for developing Go? In early days, it is 5 of us working in adjacent offices. When a wrinkle arose, it is easy to gather everyone.

That's informality doesn ' t scale to the global community today.

We ' re porting some of that to the mailing lists, but we might not having done a great job of describing the process formal Ly. Here is the steps:

1. Use Go. (Accumulate experience.)
2. Identify and explain a problem.
3. Propose and discuss a solution.
4. Implement, evaluate, refine solution.
5. Ship production implementation.

We might want to isn't proceed and go back to a previous step. It ' s an iterative and reactive process.

Different people can work on Different steps.

We explained some parts, but not the whole process.

Russ wants to explain step 2 today, since it wasn ' t covered before.

Step 2 is "identify and explain a problem." We the developers is good at this. We write tests, which define a problem so well that even a computer can understand it.

We ' re not as good in being sure that a problem is important, and worth solving.

On September, Russ reported a issue:

Error. Value

A problem that we had in very low-level libs was that everything depends on the "OS" for OS. Error, so it's hard-to-do things this OS itself can use (like time. Nano below). If not for OS. Error, package OS would not being depended on by nearly so many packages. Computation-only packages like hash/* or StrConv or strings or bytes would isn't not need to mention it, for example. I plan to explore defining a package error with an API of approximately:

package errortype Value interface { String() error)}func New(s string) Value

It was sufficient to describe the problem and then. But it took a lot more to explain to a larger audience at Gotham Go.

Timing an Event

start := time.Now()       // 3:04:05.000event() end := time.Now() // 3:04:05.010elapsed := end.Sub(start) // 10 ms

Timing an event across a leap second causes the end result does not match reality. So elapsed time can end up being negative. A Millisecond event can be timed to take-990 Ms.

start := time.Now() // 11:59:59.995event()end := time.Now() // 11:59:59.005                  // (really 11:59:60.005)elapsed := end.Sub(start) // -990 ms

Because of this problem, OSes implement a monotonic clock.

October, a bug report requested the addition of a new API to access monotonic clocks.

Russ didn ' t think that it is worth adding new API at the time.

We waited. Waiting was a good the understand the significance of the problem.

Cloudflare had a significant outage as a result of the leap second. Cloudflare is exactly the kind of company, that should is able to use Go successfully.

This meant, the problem is too important to being left unresolved. So fixed the underlying problem, and did so without adding a new API.

Explaining gradual code repair

Another problem that comes up in large codebases was the inability to handle gradual code repair.

A proposal for aliases is created, which aimed to help with that issue.

We wanted to add aliases not because it is an elegant concept and because it solved an important practical problem.

When we explained it, there were no concrete examples given. So the abstract example is hard for developers to understand and relate to.

In fall, we started over. We gave multiple concrete examples, showing how the problem arises everywhere, isn't just in Google. After people could see its significance, and we had productive discussions.

The outcome is that type aliases is added in Go 1.9.

To discuss major changes to Go on the community, we need to describe the problems well. Experience reports turn an abstract problem to a concrete one, and help understand its significance.

It ' s also a test case. Any potential solution can is tested against the problem and see if it resolves it well.

We Don ' t currently has great examples of experience reports that show what absence of generics is a significant problem.

Every potential major change to Go should being motivated by experience reports, documenting how people is using Go today, a nd how it would affect them.

These reports is the raw material for the Go 2 process.

We need your help writing these experience reports.

Post them on your blog, Medium, a GitHub Gist, etc., and add a link to the it to our new Wiki page:

Https://golang.org/wiki/ExperienceReports

Additional examples

There is a language change suggestion (in https://golang.org/issues/6815) to being able to multiply 32-bit values and store The low, and high bits:

var lo, hi, x, y uint32lo, hi = x * y

We came up with a solution, which we posted in the issue, but waited on adding it.

But now, a new package math/bits is added to help with that problem. It ended up being a new library is a better solution than a language change.

When the Go race detector was added, it is originally something that is considered as a language change too, but it wasn ' t clear how to make the work well. Instead, a better solution ended up being additional tooling, in the form of the race detector as we know it today.

Go 2 Schedule

We want to reduce divergence between Go 1 and 2. We ' ll need time to land some changes. Russ expects we might to see this begin to land in a year or so, around Go 1.12. This is speculative.

We ' re not abandoning Go 1, we ' re bringing it as far as possible along and supporting it.

We need your help. Please help us in every step along the. What we need today is experience reports. How was go working well for you, and how go was not working well. That's how we'll start talking about how we, the go community, can change go.

Blog Post

There was a official Go blog post covering this talk posted today. It goes in further detail on this topic, and you can read it at Https://blog.golang.org/toward-go2.