Go updates to tackle pain points, but Golang 2 is dead
Go Day 2022 highlights include possible Go updates to tackle compatibility, security and developer pain points such as for-loop scoping. But Golang 2 will never happen.
The Go programming language will continue to evolve with periodic improvements, but there's one update that developers will never see: Golang 2. Instead, Google will continue to follow the Go.1x naming convention to emphasize backward compatibility, which means new Go tool chains will continue to build old Go programs.
Go, a general-purpose open source language, has undergone regular updates since its 2009 inception. The changes include this year's Go 1.18 update that added support for generics, or a way to write code independent of a specific type. Developers can expect to see incremental improvements to compatibility as well as other areas such as structured logging and security, although users won't see these updates until Go 1.21 or beyond, said Russ Cox, distinguished engineer at Google, this week during a Go Day 2022 talk. During the virtual event, Google employees discussed the future of the programming language, including new potential updates to the language that developers said are sorely lacking.
One area being considered is fuzzing, a type of automated testing that continuously manipulates program inputs to find bugs. Cody Oss, a senior developer relations engineer at Google, hinted in an online Q&A during his talk that Go might structure fuzzing beyond primitives, which are basic code parts such as numeric types and strings. This will give developers more flexibility when performing security checks.
Developers underappreciate fuzzing and it deserves more social media buzz, said Go 2022 attendee Bartłomiej Święcki, core immudb developer at CodeNotary, an IT services and consulting firm based in Bellaire, Texas.
"It is a pleasant experience that can increase the security of the software we write," Święcki said. "I can't wait for improvements in this area."
Introducing structured logging
The Go team is developing a new standard library package for structured logging, which makes logs machine readable, according to Jonathan Amsterdam, a Google software engineer. Go supports a variety of structured logging packages such as logrus and zap, but with so many packages, it's hard to keep log output consistent. A proposed slog package that coexists with existing packages will fix this issue, he said.
Sotirios Mantziaris, senior engineering manager at app dev company Beat and an attendee, said he has been anticipating the slog package for years.
"If you are using other packages, you would see that everybody uses their own implementation," he said. "Some packages do not allow you to plug in your implementation at all, which results in logs that are a mess. Introducing this abstraction will start to unify everybody, hopefully, under one roof."
Jyotsna Gorle, a full stack engineer at Yelp and an attendee, was also impressed with the prospect of a standard logging package.
"Loved it," she said. "Although until it becomes a standard library, it doesn't serve much purpose, since it is very much like using a third-party Go package."
Golang plans for more compatibility
Backward compatibility can happen more often by extending the use of GODEBUG, Cox said. GODEBUG is an environmental variable that controls debugging variables within the runtime. One change under consideration for a future version of Go is to add GODEBUG to any changes that might break programs and guarantee those settings would last at least two years, he said.
I really like how the Go team is evolving the language. The backward compatibility gives the peace of mind that the code I write today won't have to go through some major refactoring later just to keep compiling.
Bartłomiej ŚwięckiCore immudb developer at CodeNotary
"I really like how the Go team is evolving the language," CodeNotary's Święcki said. "The backward compatibility gives the peace of mind that the code I write today won't have to go through some major refactoring later just to keep compiling."
Another proposed change focuses on forward compatibility, which means that old versions of Go can compile newer Go programs. Today, build fails can result in a "mysterious error" and a note about which Go version is affected, Cox said. The way to improve this experience is for an older Go version to download and re-execute a newer Go version when the module's properties need it, he said.
A third proposal is focused on language compatibility. GODEBUG runtime settings have limited effectiveness because they must apply to the entire program, Cox said. Language compatibility is much easier because it happens at compile time, which means developers can apply different settings to different packages.
Go already does this in a limited way, but Cox said an improved version would remove or fix areas in the language that repeatedly cause problems.
Other features under consideration
A future version of Go might require tagged cross-package literals in new code to avoid compatibility issues, Cox said. Untagged literals, text representation of values without attached metainformation, can sometimes fail to compile, Cox said.
Another fix in the works involves for-loop scoping, which is sometimes a pain point for Go developers, Cox said. A for-loop allows developers to write a loop that executes a specific number of times, and scoping defines access for variables. Bugs can happen in for-loops if variables get overwritten on each iteration of the loop; possible fixes include introducing iterating scope variables or pass variables as arguments to the new goroutine, he said.
However, the proposed improvements didn't satisfy every attendee. Munawar Hafiz, CEO of OpenRefactory, a bug detection and repair company, wants more refactoring support in Go to make changes in old code and upgrade them.
"They provide some support but not much," he said. "Why not? Because it is not easy. Because the language developers often do not want to be the tool developers."
Go should also add support for upgrading broken contracts, Hafiz said. Broken contracts happen when APIs, or language constructs, change.
"Some breaking changes can be fixed by refactorings, but many are not," he said.
