Google Distinguished Engineer Russ Cox, tech lead for the Go programming language, has promised that “there will not be a Go 2 that breaks Go 1 programs.”

Cox also described changes in the just-released Go 1.21 that improve forward compatibility.

In a post on the Go blog, Cox puts forward the view that compatibility is “far more valuable than any possible break with the past.” A promise of compatibility is not a new thing for Go: in 2012 when Go 1.0 was released the documentation stated “It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification.” The commitment is for source code, not binary compatibility.

That document refers to a possible future Go 2 with a new specification which might be less compatible; but Cox now says “there will not be a Go 2 that breaks Go 1 programs.”

Despite these promises, compatibility is not absolute, and Cox describes a number of cases where new versions can break existing code. Fixing buggy behavior is one example. Another is where the precision of the time.Now function was increased, and a third case is when the sorting of equal results changed, following optimization of the sort implementation. A fourth is when a default protocol changes, for example from HTTP/1.1 to HTTP/2. Cases like these mean that changes to Go can still break existing code. The team mitigates this by running tests on Google’s internal Go code. Despite this, Cox references how the Kubernetes team uses a forked copy of a function, ParseIP, when it was updated with stricter parsing. Otherwise saved configurations could have broken.

In Go 1.21, there are new features to further improve compatibility. Toolchain management means that the go command (which automates download, build, install and test of Go packages) will not attempt to build code intended for a newer version. Rather, it will automatically download an updated version, but without overwriting the current installation. 

There is also expanded use of GODEBUG, a key-value pair that can be set as an environment variable. In general, if a change does break compatibility, “we will define a new GODEBUG setting that allows individual programs to opt out of the new behavior,” Cox says.

Is Go compatibility as good as claimed? “I’ve had significant breakages with most Go upgrades. I’ve had far fewer issues with rust upgrades, and gcc upgrades,” says one developer on Hacker News. Others had run into some of the issues Cox documents. Nevertheless, overall sentiment is positive. “I started using Go at work ~2 years ago and I love it, especially for the backwards compatibility,” says another.