It has been five years since the Go programming language reached version 1.0. Since then, the team has been slowly making its way to 2.0, with version 1.8 of the language just released in February. This week, at Gophercon 2017 in Denver, Colorado, the team revealed its goals and vision for reaching 2.0.
“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,” Russ Cox, tech lead for the Go project and the Go team at Google, said during his talk at GopherCon.
Cox explained, today’s goals mirror the same goals the team had as it set out to create the programming language in 2007, which was “to make programmers more effective at managing two kinds of scale.” That included production scale and development scale. For version 2.0, the goal focuses on finding ways to fix how the language fails to scale.
The number one constraint currently is existing Go usage, according to Cox. “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,” he said.
To ensure Go 2 brings all those developers along with it, it must bring existing Go 1 source code and not split the ecosystem. To do so, the team will utilize automated tooling and minimize disruption as much as possible.
The ship and deliver Go 2 successfully, the team will handle backwards-compatibility feature by feature. “First, it keeps the Go 1 releases on the usual schedule, to continue the timely bug fixes and improvements that users now depend on. Second, it avoids splitting development effort between Go 1 and Go 2. Third, it avoids divergence between Go 1 and Go 2, to ease everyone’s eventual migration. Fourth, it allows us to focus on and deliver one change at a time, which should help maintain quality. Fifth, it will encourage us to design features to be backwards-compatible,” he said.
The Go programming team also hopes to hear back from the community on what works and doesn’t work for them as well as real work examples and experience.
