Chris Siebenmann is a Unix sys-admin for the CS department at the University of Toronto. He recently saw a tweet asking about the possibility of community-implemented generics for the Go programming language, and posted a widely-read response on his blog.
“There are many answers for why this won’t happen, but one that does not usually get said out loud is that Go is Google’s language, not the community’s.”
Yes, there’s a community that contributes things to Go, some of them important and valued things; you only have to look at the diversity of people in CONTRIBUTORS or see the variety of people appearing in the commits. But Google is the gatekeeper for these community contributions; it alone decides what is and isn’t accepted into Go. To the extent that there even is a community process for deciding what is accepted, there is an 800-pound gorilla in the room. Nothing is going to go into Go that Google objects to, and if Google decides that something needs to be in Go, it will happen.
(The most clear and obvious illustration of this is what happened with Go modules, where one member of Google’s Go core team discarded the entire system the outside Go community had been working on in favour of a relatively radically different model. See eg for one version of this history.)
Or in short, Go has community contributions but it is not a community project. It is Google’s project. This is an unarguable thing, whether you consider it to be good or bad, and it has effects that we need to accept. For example, if you want some significant thing to be accepted into Go, working to build consensus in the community is far less important than persuading the Go core team. (As a corollary, sinking a lot of time and effort into a community effort that doesn’t have enthusiastic buy-in from the Go core team is probably a waste of time….) On the good and bad scale, there is a common feeling that Go has done well by having a small core team with good taste and a consistent vision for the language, a team that is not swayed by outside voices and is slow moving and biased to not making changes.
The essay also concedes that “I like Go and have for a fair while now, and I’m basically okay with how the language has been evolving and how the Go core team has managed it. I certainly think it’s a good idea to take things like generics slowly.
“But at the same time, how things developed around Go modules has left a bad taste in my mouth and I now can’t imagine becoming a Go contributor myself, even for small trivial changes.”