In June 2025, the Go team made a somewhat unusual announcement. After a lot of effort and an almost incredible amount of community discussion, they decided to stop all work on their most outstanding, most requested feature.
Improved error handling syntax has been on their radar since the early days of the language. Many Go developers have just assumed that they would get to it eventually, and you can see why. Error handling in Go is verbose and cumbersome and it makes the code much harder to read. Furthermore, it itself is a source of errors, requiring boilerplate that is subject to bugs that arise from typos that can be all too easy to write and yet hard to catch by code review.
In this matter, the Go team can be applauded for a few things. They have followed all of their rules for community engagement, at significant expense. The Go team believes in consensus-based decision-making and they have repeatedly tried to find consensus on this matter, without success. While it seems there is a consensus around the problem itself, no solution has achieved widespread support.
The team also has a strong commitment to backwards compatibility. In this case it seems to have gone beyond literal backwards compatibility (most of these proposals introduce additive syntax) to embrace the spirit of backwards compatibility more generally. Since many of the proposals would require developers to learn the new syntax if it is included in libraries that they import, this burden of learning and adapting to the new syntax is also perceived by some as a reasonable objection, on the grounds that it breaks backwards compatibility in spirit (my words).
Now this gets us to a few of my interests when it comes to software development. Many communities take these two principles -- backwards compatibility and consensus-based development -- as articles of faith. But they can be extremely costly to implement. In this case, they appear to have nixed multiple otherwise viable efforts to solve the Go community's most up-voted problem.
So what if the Go team had given up the consensus constraint? Consensus-based decision-making puts a lot of power in the hands of relatively small factions. If the bar was lowered to 60% agreement, say, what would have happened to the opposed 40%? How many of them would end up adopting and even come to love the new syntax? How many would actually leave the community over this change? Few, I'd wager.
The Go community has a proverb about its beloved go fmt tool which says that "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite." This is an appealing bit of wisdom about compromise in community decision-making. Is it really possible to achieve a solution like go fmt with consensus-based decision-making?
Ultimately, although costly to implement, consensus-driven decision-making is in a sense the path of least resistance for any organization. If virtually everyone in the community is in agreement, then the decision makes itself. Perhaps there is some leadership involved in building the consensus in the first place but after that point making the decision is nearly automatic. And when decisions turn out to be wrong in retrospect, well it wasn't your decision, it was the community's. In this model, any mildly controversial proposal is often quickly rejected.
By contrast, decisions made with a more divided community depend much more on leadership. They call for a vision of the future and the pragmatic tactics to get there from here. This approach can be risky, sure, but consider the upside.
The Go team has now thrown a lot of effort into this problem with little to show. But what if they chose to pick one of the most popular solutions, and said to the community, "This is our best path forward. We are going to try it and see what happens. This one is going to be like go fmt. No one is going to love the new error syntax, but everyone is going to love that we have a workable error syntax." That might be considered an example of leadership. And it might just work.
Think about all the extra community churn that would have been saved, all of the comments, and back and forth, the proposing and vetting of one viable solution after another. That avoided effort could have instead been poured into other features.
Regarding backwards-compatibility, I would honestly just ask the team to live a little. As long as backwards-incompatible changes are flagged as such, I say just go for it. Not all the time, of course, but when there is a compelling reason to add new syntax, just go ahead and bump that major version.
There is really nothing special about having everyone in the community on the latest version. Having multiple active versions or branches is standard for plenty of languages, including Go. You can have a branch for more experimental changes and only port them back to the main branch when you're absolutely sure they make sense. I think that's what the Go team does in general, but when it comes to introducing compatibility-breaking changes they are being extremely conservative.
In this case it really is the spirit of backwards compatibility that the Go team seems to be concerned with. They are already good at releasing tooling that helps upgrade legacy code. And the community can become better at handling major version changes. Upgrading really isn't that much harder than many of the other programming tasks that Go developers currently take on.
Having said all this I don't expect the Go team to change their course on this one. These practices are too deeply ingrained. I do hope, however, that this case can provide an example for other teams that are thinking about adopting consensus-based decision-making or making strong backwards compatibility promises.
Perhaps there is a little evidence here to support the idea that these practices can lead to sub-optimal outcomes, at great expense. Perhaps it is worth investigating more efficient decision-making methods and more flexible ways to make large changes to a product or platform. Perhaps we can all live a little while taking a leadership stance that is more resilient to minor divisions in our communities.
