When you hear most critics of Go (or any language for that matter), they talk as if Go is merely an alternative syntax for their favorite language. Of course they're bothered by lack of a missing features and unfamiliar ways. As tired of an analogy as it may be, programming languages are like natural languages. Trying to learn Japanese by translating sentences, idioms and proverbs from English word for word will only end in frustration and confusion.
If you read the history of Go, the whole point behind its creation (as with many others) was to start with a clean slate so new norms and ways of doing things could form, in service of large distributed teams and long term maintainability. Lack of generics, as unrelated as it may seem, is actually the result of the those and other goals. Specifically, Go authors avoided complicating the language, runtime, and compiler early on and thereby avoided negatively affecting long term maintainability of both the language and the code written for it (v1 compatibility promise) before having a good grasp of how generics should be implemented in this new language or if it should be at all. Copying the so called tried and tested implementations from existing languages would make little sense as generics are so intertwined with the rest of a language.
TL;DR approach learning programming languages like you would approach learning a new natural language with the purpose of living among its native speakers.
Most critics of Go are well aware of its history and purported design goals. The problem is that the set of features that actually are in Go (like channels) versus those that weren't (like generics) or still aren't (like enums) doesn't really make sense when taking those design goals at face value.
For example, generics. Like you say, the original claim was that they didn't want to do them because they thought that more time is needed to figure out how to do them "right". And so they waited for a decade, and ended up implementing them in a way that's not fundamentally different from most other languages that had them all along. What, exactly, was gained here to justify the productivity lost while waiting?
I will also add that to someone who knows a few PLs, Go is a very boring language in a sense that there's very little new there, neither in terms of individual parts, nor in terms of how they're combined together. So the notion that this combination is somehow so unique that its evolution is like walking on untested ground doesn't pass the smell test.
> What, exactly, was gained here to justify the productivity lost while waiting?
The goal isn't to wait long enough to come up with something novel. That's what research projects are for, and Go is on the exact opposite of the spectrum. If after deliberation, it turns out that a mostly similar solution is the way to go, then that's doing it "right".
Also, the lost productivity that keeps getting mentioned is overblown. The minority who actually need it (a subset of those who ask for it) are, well, a minority but a loud one. I have developed in Go for 8 years. I only ever reached for generics twice and in both cases, copy pasting the implementation in different types added a insignificant effort.
> Go is a very boring language in a sense that there's very little new there
You hit it on the nail! It's boring. That's what you need when you're targeting large distributed teams and want your code base to survive decades and still be readable and navigatable by pros and amateurs alike. You don't want clever or smart. You don't want cutting edge and novel for novelty's sake. You don't want magic. You don't want to have to keep the context of 20 files in your head to understand one line of code. You don't want a syntax that can be interpreted in 10 different ways in different contexts, ... . You want the sweet spot between simple and practical.
Back to:
> Most critics of Go are well aware of its history and purported design goals.
Your comment about Go being boring and its lack of novel features, is clearly demonstrating that you've either missed or misunderstood the design goals. And many similar comments on other parts of the language from others I've interacted with is what I was basing my parent reply on.
Right, the design goals are it is a language for people not clever enough to deal with programming languages.
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1"
"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2"
Approaching 50 here, and no major issues dealing with project deliveries across Java, C#, JavaScript, TypeScript, C++, Transact SQL, PL/SQL, PowerShell, bash, ....among plenty of other stuff, naturally depending on project specific workloads.
Maybe it is some devs that can't fathom how to transport water buckets to the top with all those stairs.
> Approaching 50 here, and no major issues dealing with project deliveries across Java, C#, JavaScript, TypeScript, C++, Transact SQL, PL/SQL, PowerShell, bash
Very commendable — I don't touch JS that I didn't write. Forget C++ altogether :D
I didn't mean my comment as a negative — in fact, I see all those attributes as essential so one doesn't produce junk at a fast rate just cause s/he can code for 20 hour straight and refactor endlessly. Of course I know devs older than me who are still in mass production mode and don't deliberate much. In fact, I often have to ask people to slow down and seek simpler and lazier solutions for their sake and mine further down the line.
It's not boring in a sense of being boring to learn, read, or write. Ada or Java are languages that are "boring" in this sense, but which nevertheless offer far better abstractions than Go.
Go is boring in a sense that it's not innovative. Go's claim to innovation is that the feature set is tuned for new users, but that's not actually the case.
Certainly a better take than 'I don't like generics, it's somehow less complicated to downcast interface{} everywhere'. It was very interesting reading the justification for not having generic methods, and how that clashed with my assumption of what generics should be, or for that matter what methods should be. Go is the spiritual successor to C, IMO - for all that people use it nowadays for its low-level capability, people forget that its original purpose was to do what every other language of its day did, but way, way more simply.
> in service of large distributed teams and long term maintainability.
Except those didn't really manifest. The opposite was actually true, golang is worse for large teams and maintainability compared to languages like Java and C#.
> Go authors avoided complicating the language, runtime, and compiler
Which ended up complicating end users' code. There is no way around it, complexity has to exist in one space or the other. They just made writing the compiler easier, which made writing and reading golang code much harder, and ended up with a weak language.
Years of experience working on several large golang projects, and seeing what sorts of issues and bugs programmer face when working on them. Things that they wouldn't have encountered in Java or C# for instance.
Furthermore, the burden of proof is on the golang authors making the claim. I have not seen any rigorous studies that underly the design decisions they claim will result in more maintainable large code bases.
> How do you figure that? I see large projects like Kubernetes and Docker thriving with contributions.
That's despite of golang, not because of it. C is quite bad for large scale projects, yet Linux has a lot of contributions because it is a large project (a tautology of sort).
> Some users, sure. Majority of projects, as evident in Go annual surveys clearly shows they are doing OK without it.
A biased survey that mostly pro golang people would take anyway.
If you read the history of Go, the whole point behind its creation (as with many others) was to start with a clean slate so new norms and ways of doing things could form, in service of large distributed teams and long term maintainability. Lack of generics, as unrelated as it may seem, is actually the result of the those and other goals. Specifically, Go authors avoided complicating the language, runtime, and compiler early on and thereby avoided negatively affecting long term maintainability of both the language and the code written for it (v1 compatibility promise) before having a good grasp of how generics should be implemented in this new language or if it should be at all. Copying the so called tried and tested implementations from existing languages would make little sense as generics are so intertwined with the rest of a language.
TL;DR approach learning programming languages like you would approach learning a new natural language with the purpose of living among its native speakers.