With the launch of Go 1.21, Google engineer Russ Cox says there will never be a Go 2 that “breaks Go 1 programs.” In doing so, he reiterates a promise made for Go 1.0 in 2012.
“Boring is good. Boring is stable. Boring means you can focus on your work, not on what’s different about Go,” Cox asserted in a blog.
Nuance
Still, Cox adds some nuance. The issue is source compatibility, which does require a code recompile when using a new version of Go. However, he says the main objective is that later versions of Go do not break APIs.
Through internal testing at Google, the team behind Go can usually find potential compatibility issues before an update is released to the outside world. Sometimes that means a desired new feature requires extra attention. For example, during the testing phase, an improvement to the time.now feature was found to lead to undesirable results. Currently, the accuracy of the time measurement is to the microsecond, while a proposed change would improve this to nanosecond precision. In the end, version 1.21 did get this upgrade.
Different from the rest
Sometimes there are changes that make Go look more like other programming languages, such as how it handles input changes, or in other words when a function changes inputs or how it processes them. In that regard, they made changes that didn’t break anything within Google, but did at others. For example, the team behind Kubernetes found it undesirable to change its handling of leading zeros, or unnecessary zeros before the number. Cox says that a parity with other programming languages on this front won’t happen until Kubernetes environments won’t have problems with it.
Looking ahead to Go 2
Go 2 would never be a specification that breaks Go 1 programs, Cox asserts. Instead, the focus would instead be increasingly on compatibility, with updates to remain “as boring as possible.”
Also read: Google tests develop environment with AI help: another GitHub Copilot story?