The Real Problem with Go
Posted 1 Nov 2022
A personal blog about programming and socialism.
These articles should not be taken as the official view of any organisation.
Posted 1 Nov 2022
Hint: It’s not error handling.1
Excuse the provocative title. I am actually a huge fan of the Go programming language.
The real problem is human, and it’s about human processes.
Critically, I do believe that the Go project is healthy enough that this can be solved.
Every change needs approval from at least two Google employees. Their code review platform, Gerrit, is meant to automate this. But it will happily assign your pull request to ex-employees who haven’t logged in for years.
You need to know exactly who to talk to, on a different channel, to get things moving again.
I’ve been trying to merge a single line bug fix for three months, and it has taken me repeated effort to get it moving. I really want it merged before the release freeze for the next Go version, which might be in about a month.
This is in what I consider a fairly critical section of Go (support for text internationalisation), which is half finished, and where I counted 150 “TODO”s in the comments.
There’s a lot of interest from (non-Google) developers in improving this area. But how can we ever do anything substantial, if every one-line change has this much friction?
Even if Google ultimately calls the shots, the Go project is commendably transparent and publishes the minutes of several weekly meetings. A month ago, the compiler and runtime meeting minutes revealed an interesting discussion about processes and change requests:
… we have to reduce our processes… little things like the two Googler review rule.
Last week there was a big uptick in contributors sending a huge number of tiny changes. A lot weren’t substantial improvements and could have introduced bugs…
I think we should push back more… it’s a zero-sum game.
The time we spend reviewing these takes away from time we could be improving go.
Some folks who send these sorts of will turn into useful contributors over time… if [a specific] Go community is getting more involved, we want to encourage that.
I don’t mind the reliance on Google maintainers. It has advantages and disadvantages.
But if it’s going to continue, and it’s a bottleneck, then I think the Go project needs more resources.
Last year, Google pledged to spend:
This is a noble and worthy thing to do, but it’s incomprehensible that their own open source product doesn’t get a slice of this.
Google, of course, have put a lot into Go already. They have no obligation to put a penny more into it. But I feel like funding even just one or two extra maintainers would have an outsized impact.
In an ideal world, when you fix a bug you can send a fix, get it reviewed, and have it merged, without having to chase it. Where this doesn’t happen, we have to become “amateur maintainers” and learn the ins and outs of how maintenance happens, who to talk to, etc. That’s fine - when the world is less than perfect, an engineer’s instinct is to work on fixing it.
What gives me confidence about the Go project is that I’ve seen how problems, including non-technical problems with processes, can be addressed through collective discussion.
There is no shortage of people willing to volunteer their time to improve parts of Go.
What they, and the core Go developers need, is maintainers with the time to coordinate the work.
See Rob Pike Reinvented Monads. Now that Go has generics, extrapolate that argument to the present day.