Googler here, but these are my own opinions formed from less than a year at the company. My observation of Google's culture is that it can be very difficult to

Googler here, but these are my own opinions formed from less than a year at the company. My observation of Google's culture is that it can be very difficult to see the ways in which they dominate projects they participate in because it's very difficult to keep perspective on how even small investments by Google tend to overwhelm the volume of other contributers project. Google has a lot of great, productive engineers and when they turn those folks fulltime to open source projects the results are very impressive. I feel this too with the open source work I'm adjacent to. Go's situation is further exacerbated by the somewhat normal expectation at Google that programming systems often feel very top-down mandated to new employees (even if I think reality is that there is just a lot of cultural and tooling inertia there; in reality you can use whatever you want if you can make a case for it). The recent "fix Python's broken batteries" thing comes to mind as a conflict long overdue but suppressed by that culture of top-down mandates. Indeed, even without insider knowledge, rumors speak in hushed tones about how top-down GVR's leadership of Python was during his time working with Google. It seems like after he left, that notion has softened. So even if folks on the Go project don't mean for it to feel like "google's language", it's still entirely possible that it does feel like Google exercises a lot of control over Go. This is a really significant and old challenge for big companies interacting with open source, but it's one that language teams have only recently started to really face at scale (see also: Rich Hickey's conflict with the Clojure community over overly biasing Clojure towards Datomic's interest and not helping to prioritize or yield resources or his oversight mechanisms to other people's needs). The Go team was (and has been) also been slow to address the community's obvious and vocal need for some sort of templating solution. While it's fair to appreciate the difficulty of these discussions and designs, it's also the case that the Go project communicated their reservations rather poorly and created a lot of ill will that the language still suffers from today. As languages are starting to open up and become more community driven (again, it used to be a lot more like this with small scripting language communities), the difference between a carefully guided language like Go and a language where anyone an contribute all the way down to the compiler and have a fair expectation of getting it included (like Haskell's GHC project) start to really contrast.