Sorry, but I just don't buy it.

Performance just isn't the problem people say it is. I've done a lot of Python development over the last 12 years, and in that time, I've run into lots of performance problems, but none that would have been easier to solve in Go and none that were particularly hard to solve in Python. In most cases you're just offloading onto libraries (i.e. Pandas or MPT). I've dipped into C a handful of times, but that was more of a "could" than a "had to".

I'll give you a point on tooling--Go's tooling is pretty good. There are a bunch of languages with good tooling these days, but compiling easily to a single binary blob is still a pretty winning feature. But usually that sort of stuff is automated out in the first week of development anyway--is that really enough to justify choosing a language?

Ecosystem? I'm not impressed. There are like 10 languages with healthier, more active ecosystems.

"Simplicity" is generally a pretty bad argument, because what's simple is so subjective. My observation is that simple problems are simple in Go, which makes it a great language for demos, but if you actually try to solve complex problems with it, the language completely lacks features with sufficient abstraction to make complex problems simpler. Where other languages you end up spending 20% of time solving 80% of problems, and 80% of time solving 20% of problems, with Go it's more like you spend slightly less, 15% of time solving 80% of problems because of the simplicity, and then you spend 300% of time solving the other 20% because the actual hard stuff is much harder in Go.

Readability: this sort of goes back to the simplicity thing. Sure, go has less boilerplate than some languages, but that only matters for the simple stuff. If you get into, say, a complex networking algorithm, Go code is going to get lost in all the nonsense of making sure threads share memory properly. I won't argue that, for example, Erlang's syntax isn't a bit ugly, but I can explain my networking code in Erlang to someone who doesn't know Erlang fairly easily because of message passing.

Learning curve: beating a dead horse here, but just because it's easier to learn to solve simple problems in go, doesn't mean it's easier to learn how to solve professional-level problems with go, let alone industry-leading problems which actually constitute the competitive advantage of a business.

Go steals the mindshare because people saw Google were using it and mistakenly thought that if Google were using it, it must be good, even though almost nobody has the same problems as Google.

> So yes, Go is now looking at generics because it’s tackled the more important problems. Not because it was the most important problem and the developers were just too stupid to understand.

Just to be clear, I didn't call anyone stupid: on the contrary, I think the developers fell into a trap that is particularly dangerous to smart people: we think that because we're smart, we already know the best way to do things. That's not stupid, it's ignorant. I don't mean that to be insulting although I'm sure you'll take it that way, but I'll say that ignorance is fixable.

It's telling that in your post you just spit out a bunch of buzzwords without any comparison to any other languages, which is pretty much how Go got here: Go developers generally only think Go is great because they've never used other decent languages. If you're coming from C, then you can be forgiven for thinking Go is the bees knees, but that's comparing a 50 year old programming language with a 10 year old one--C has lots of problems, but there are historical reasons for those problems. Go has problems that Gophers don't even know are problems, because they've never spent enough time working in a language that actually solves those problems. And there's no excuse for it, because Go has no historical reason for not solving those problems: a lot of them were solved by other languages before Go existed, and the developers were either ignorant of the existing solutions or thought they knew better (and definitely didn't, in my experience).