Fixing the Issues That Come with Scale – InApps Technology 2022

The fifth annual GopherCon kicked off this week in Denver with a keynote by Russ Cox, one of the Go programming language’s key contributors, articulating the most important evolutionary hurdle the language has ever faced. Is it working or not working for developers? Will anyone fix its failures to scale? And if the next major version of Go adds the features it needs for scalability on modern platforms, will it lose the speed and reliability Go has been known for as a systems development language?

“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,” stated Cox, in a personal blog post Thursday summarizing his keynote. “We can do only a few of those major changes. We will have to choose carefully.”

The majority of Cox’s talk revolved around the Go team’s recent announcement of its plans to release Go 2. Although Go 1.9 is still on schedule to be released in August, the presentation left the audience looking even further into the future.

Cox touched on the importance of the language, describing problems in a way that portrays their significance to developers in other environments. The goal of attaining this capability will shape the development of Go 2, he stated, explaining how this development process has already proven itself effective in Go 1.9.

“In the early days of Go, when there were just five of us,” wrote Cox in his keynote summary, “we worked in a pair of adjacent shared offices separated by a glass wall. It was easy to pull everyone into one office to discuss some problem and then go back to our desks to implement a solution. When some wrinkle arose during the implementation, it was easy to gather everyone again. Rob and Robert’s office had a small couch and a whiteboard, so typically one of us went in and started writing an example on the board. Usually by the time the example was up, everyone else had reached a good stopping point in their own work and was ready to sit down and discuss it.

“That informality obviously doesn’t scale to the global Go community of today,” Cox continued.

First and foremost, Go 2’s main goal will be to fix the most significant ways Go 1.x fails at scale. Cox cited two examples in which Go faced significant issues with scaling, demonstrating how effective communication of the system’s situation ahead of time might have prevented failures.

Experience reports, he said, will really make the development of Go 2 more efficient. In keeping with the language’s name, Cox stated that an experience report “describes the significance of a problem in a way that someone working in a different environment can understand.”

Problems found through community experiences, he added, need to be clearly explained and effectively presented if Go is to continue evolving.

Cox warned about the potential fragmentation of the language’s ecosystem if both versions 1.x and 2.x co-exist. All existing Go 1.x source code must be able to mix effortlessly with Go 2.x source code and vice-versa, he said. Backwards compatibility will be vital to the success of the language, he said, suggesting that the backwards-compatible parts of Go 2 should get shipped feature-by-feature with successive releases of Go 1.

There are five key advantages to this approach, he said. Again, citing from his personal blog, “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.”

As a community supporting an open source language, Go’s community is just as responsible for shaping the release of Go 2 as the Go team itself, Cox asserted. To significantly refine Go, experience reports need to become shared,  exposing failures and the need for new features.

Feature image: By Eric Zelaya of Ardan Studios based on the Go gopher by Renee French.