Go's very lack of expressive power is what helps make it an enterprise language. It's simple enough and limiting enough so that a non-brilliant developer has little trouble picking it up, and is unlikely to run into a complicated corner case. As statistics inevitably have it, half the developers are below median level, by definition.

The really smart stuff in Go, like goroutines scheduling or lightning-fast GC, is all under the hood, and you don't get to touch it, and don't have to.

You can see the same pattern in other wildly successful languages of the past, such as Fortran, Cobol, Visual Basic, or PHP.

Having one of the largest IT corporations backing the language and actively using it does help, too. But I would not exaggerate this factor: Python got to the top without a comparable corporate support from its creators.

Yeah but now that we have generics the bar has been raised right?

I’m not giving generics up, that’s for sure.

Developers in this categories are not going to say "LOL J2EE" or "LOL Go". They will do whatever being asked and collect paycheck in return. If they chose to be independent voice, they are going to be asked to leave and make way for devs who comply.

Is there a Go equivalent of Object?

In a microservice world, I habe to send a request to 6 microservices and I want to do them concurrently not sequentially

Cancellation tokens are harder, though.

Yeah, but Google did a lot for python adoption.

What? Generics ≡ parametric polymorphism.

And for collections Go has other tools (like generator if you really want to). Overall in the 2ish years of writing Go, I only missed them when I was learning the language coming from years of Java.

Interfaces: same API, different source code. Generics: different APIs, same source code.

This is why Go needs to have generics.