2) This is a complete non-issue -- with Google infrastructure, it's enough to not be significantly slower than C++, which is really a low bar.

3) Go is definitely easier to use than C++, I agree. That said, it also has enough of idiosyncrasies to make it familiar mostly to people used to writing Plan 9 C, starting from "nil" instead of "null", and ending with "dial" instead of "connect".

4) I never noticed how it is any easier to do it than in, say, Java. Most of the large Go programs I've seen tend to leak goroutines, for one thing.

5) Maybe it was designed for these, though I don't quite see the way it's better suited for network applications than, say, Java.

6) It's also a total non-issue at Google.

I have a year of experience writing Go tooling and network applications at Google, and it definitely wasn't enough for me to see the light. The rest of my team had quite similar experience (except of one guy who was a Go fan already before joining the company), and we would often make fun of Go's inconsistencies, idiosyncrasies, and the whole NIH approach of the language authors and maintainers.

Go is not bad language, it would have been great if it was 1989, and your only serious alternative was writing ANSI C. Unfortunately, it's been almost two decades since the 80s, and we figured out some things in the meantime. We now know how to do generics correctly, for one thing, and we already understood that null pointers have been a billion dollar mistake. The worst sin of Go though is that in the true "worse is better" spirit of Unix, it filled a gap for a better C++ by being only marginally better, taking away space for other, actually better contenders that don't happen have a billion dollar company backing them.

You need to learn more languages (and really learn them).