Okay, fair enough ... but Go was always designed to be a small language with a limited set of features. Many reasonable requests may very well be reasonable on their own, but don't fit with the design aesthetics. It's like trying to add Common Lisp features to Scheme: that might be considered reasonable by some, but it doesn't really fit with Scheme's design. They kind of tried with R6RS and it was massively controversial, and many Scheme implementations stuck with R5RS.
This is the part that so many people don't seem to understand. They confuse "trying to maintain Go's minimalist design aesthetics" with "not open" and "unwilling to listen". Those are not the same things!
Some of the most frequently quoted examples all include things that have either been implemented, or at least seriously considered: monotonic clock, package management, generics (not implemented but Go Core team proposals go back to at least 2010). Arguably, some things took rather long, but again, Go is a small language and changes are discussed and considered for longer than most others. Many consider this good, as it provides a stable working environment to "get stuff done", which is the entire point of Go.
It's also not clear to me that exactly "community-driven" means? The entire community voting on all proposals? Accepting a proposal as long as a subgroup is loud enough? Very few projects – if any – operate like that. There is always a comparatively small group of core developers who, in the end, get to decide.
The design goal for Go seems to be to make a language where there is only one way to express a given algorithm.
They are trying to create a language where it is impossible to be clever.
This is not bad thing in itself, except when it starts to remove features that allow you to write clearer code.
For example I have a Java application that connects to a database. I _like_ that I can just let the transaction die for any uncaught exception that bubbles up from the DB layer.
I like that better than the idea of having to 'handle' a thousand possible errors from down there that I don't even understand. In some cases exceptions make for clearer code.
And don't even get me started about the lack of generics. That is a glaring omission that shows lack of understanding of the human factor in language design.
That they didn't anticipate this obvious feature makes me question the purity of the aesthetics.
This is all fine, and they are of course free to leave out whatever features they want: this is what makes it Google's language, after all.
1: Just one from today, inconsistent arithmetic with Durations.
* nil interfaces.
* duration arithmetic (easy to avoid once you understand it).
* multiple ways of instantiating things (var vs new vs literals)
