Make your data boring
In 2012 the authors of the Go programming language published a document that made clear their intention for backwards compatibility:
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. … Go programs that work today should continue to work even as future releases of Go 1 arise.
Last August, 11 years later, they followed that up with a blog post on compatibility, where they reiterated that commitment.
They admitted this focus on compatibility is a bit boring, but argue:
Boring is good. Boring is stable. Boring means being able to focus on your work, not on what’s different about Go.
This stability gives developers the confidence to invest in Go for large, critical software applications like Kubernetes, Docker, and the secrets manager vault.
If Go, the 7th most popular programming language and one that has recently been growing in popularity can be continue to add features without breaking compatibility, why is it so hard for us to manage our data schemas to prevent breaking changes?
Why can’t our data be boring?
What I find with data contracts is there is an initial aversion to applying change management to data because we need to change it often. Some say we need to innovate.
But once data contracts are implemented I see very few of these breaking changes introduced.
That’s because they require a new major version to be created, which has some friction associated with it, so data producers spend more time designing a good data structure upfront and more time thinking about how to evolve their data without breaking their contract.
That stability then gives data consumers the confidence to invest in building critical applications upon the data.
It might be boring, but compatibility and change management is crucial for organisations who want to realise the value of their data.
So, when should we expect a version 2 of Go? Surely at some point they’ll need to make a breaking change?
That’s a question addressed in that August 2023 blog post, and:
The answer is never. Go 2, in the sense of breaking with the past and no longer compiling old programs, is never going to happen. […]
There will not be a Go 2 that breaks Go 1 programs. Instead, we are going to double down on compatibility, which is far more valuable than any possible break with the past. In fact, we believe that prioritizing compatibility was the most important design decision we made for Go 1.
So what you will see over the next few years is plenty of new, exciting work, but done in a careful, compatible way, so that we can keep your upgrades from one toolchain to the next as boring as possible.
Go is boring.
Make your data boring too.