[nine_k]

I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first.

Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority.

Frankly, there is a number of reasonably nice languages that do provide generics, good / great type systems, good / great package management, decent async features, and quite decent performance: Rust, Nim, Crystal, ... all the way down to Haskell. Go is not competing with them at their strongest features. Instead, it's in the sweet spot of simplicity, fast build times, reasonable hygiene, and trivial deployment. It's the "getting job done" mentality which worked so well for PHP and Perl back in the day. There is a considerable demand for that.

[coldtea]

>I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first.

Many large users writing in company and project blogs have mentioned lack of Generics as a pain point, so that distinction doesn't go very far.

>Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority.

Go was not created through some official decree to create a Google language, nor was it mandated to be used or to have some timeline to convert other stuff to it, etc.

It's just a project started by some Go people with the idea "let's examine what a language appropriate for Google's programming would be" -- but using their personal ideas of what Google style programming would need, not something requested, researched etc by Google as an organization. In other words it started as a glorified 20% project, and today it's not any more official in Google than C++ or Java is.

[nine_k]

I suspect that Rob Pike's and Russ Cox's work is paid for by Google.

But even if it were not, I suspect that heavyweight users like Google do have a weighty say, just because of the sheer amount of practical experience they have with developing and running software using the language. Just like Mozilla, I suppose, do have a say in the development of Rust.

[steveklabnik]

We’ve actually worked a lot to ensure that Mozilla can’t dictate what happens with Rust; we run a consensus based process, and while Mozilla has the largest single group of people involved in leadership, it’s still a very stark minority.

As a huge production user, Mozilla’s needs are still important to us, but we think of Rust as an open source project Mozilla contributes to, not a Mozilla project per se.

[tedunangst]

I wonder if this is good or bad. Sometimes it helps to have that singular vision. I think here of all the systems C coders I know, who have never used complex numbers, yet that finds its way into the standard.

[kibwen]

As a Rust user outside of Mozilla, it's very good. Rust would have had a hacked-on OO system solely in order to implement the DOM in Servo if browser engine hackers were the only ones with a voice. :P

It's fair to be concerned at the potential evolution of a language that doesn't have a BDFL (I myself came to Rust from Python, after all), but in practice I've come to trust the Rust devs as having very good taste (objective, I know!) and a strong resistance to maximalism (regardless of what some may claim... the list of features removed from the language is longer than the list of features that it has!).

[steveklabnik]

I think in general, the teams, and especially the core team, have a "singular vision" in the big-picture case; this helps. It really can go any way though, I've also seen BDFL projects where the D doesn't care about what the community wants, which ends up with that complex number problem too.

[coldtea]

>I suspect that Rob Pike's and Russ Cox's work is paid for by Google.

They are. The distinction I'm trying to make is they have not been tasked to "create an official Google language for Google scale projects", nor what the language officially adopted as "THE" google language the way e.g. Kotlin was officially adopted as a language for Android programming.

Some googlers (Pike and Cox among them) sat and designed a language that they thought would be good for Google scale programming (according to their ideas and experience) and they went and implemented it. Google paid their salaries the whole time, but at least at first, not for the purpose of creating such a language. After the language is out it paid, and even added more people, to keep it going --it gives good PR, and can be used internally here and there, so that's worth it to them.

It's just not "the Google language" in the way Obj-C/Swift are the Apple languages and C#/VC++ is the MS one (the company heavily investing in them, explicitly asking them to be built, suggesting their use everywhere, etc. For Google it's more of a side project than what e.g. Lars Bak worked on.

[hackerfromthefu]

Actually I think it's one of half a dozen languages whose use is mandated at Google