-- Rob Pike
And there are other hints on https://talks.golang.org/2012/splash.article
I'm a relative expert in some domains, but I just find the fancy languages tiresome. I even find so called experts who find it condescending to use a straightforward language tiresome. Seriously - these so called experts never actually deliver any actual product. They just loop around writing line noise that is unreadable.
If you code with others, look into the idea of write-only languages. I think you'll find some of the ideas behind go make some more sense if you understand what they are working to avoid.
I don't hate generics, but don't think they are critical to go's success.
You may argue if Go finds the right compromise between giving enough power to their users and not allowing them to shoot themselves in their feet, but the general premise seems to be a very sound one to me.
I believe the designers of Go are onto something.
It's not just the code, but how the code will evolve over time, after a few years of having dozens or perhaps hundreds of programmers modifying it.
In a large shared code base the following dynamic plays out.
* A programmer is assigned to fix a bug, or add a feature.
* His reward for that task is limited to whether he succeeded in achieving that task.
* Even if he is rewarded for improving the codebase overall (refactoring), this introduces much more risk than simply making his changes and getting out.
Basically, everyone wants to get in, make their change, and get out. Now iterate this a few thousand times.
Really it's just the tragedy of the commons, and codebases rot because of it.
The problem is magnified if the language encourages lots of complicated abstractions and meta-programming, because abstractions are difficult to evolve incrementally.
Honestly, I just see Go as a reaction against C++ in this regard.
I still believe however, that the Go team went too far in leaving out features, especially in the areas of generics and error handling. I mean both create more code, so what if it's simple code?
Then the problem becomes that you just have more lines of code to maintain and test.
 And for twenty years I was a freelance consultant brought in to untangle big pile of mud codebases for projects in crisis.
 See the concepts of assimilation vs. accommodation in psychology. Once your abstractions need to accommodate an inconvenient new fact, then it takes a lot of disruptive effort to fix the problem.
Enjoy the video from 00:20:40 up to 00:21:10.
I wasn't suggesting that you'd deliberately make up the quote, but you can find it all over the place without a proper citation, so I thought it was possibly apocryphal.