I can't speak for him, but the issues that make Go not interesting at all to me (and I believe, to a lot of other C++ coders) are automatic GC, lack of generics and lack of template metaprogramming.
The thing with Go is that it is (was?) marketed as a system's programming language. Go might work as a replacement for Java, but Java is not for system programming.
Whoever decided to say Go was capable of it either has no idea what systems programming means or was being deceitful. Go can not replace C++; these languages don't solve the same problems.
I always say, all of these "replacements for C++" don't feel like C++, they feel like statically-typed Python. Which is great, if you want statically-typed Python. There's a lot of fantastic uses for statically-typed Python.
But they're not C++. As soon as you tie the whole language to a garbage-collector and leave out any real mechanism for metaprogramming or even simple generics, you've lost me.
Pure text-based lexical macros like templates are a weapon of last-resort for language design... but it's not an optional one. Dynamic-typed languages cheat by offering a simple "exec" statement/function. Static languages have a religious objection to offering a first-party preprocessor, because they have the hubris to believe they can solve every possible problem ever within their language.
Nobody is that good at programming language design. Not Pike, not Gosling, not Ritchie, not anybody. The difference is that Ritchie's team knew that, and didn't try and pretend that every single thing could be easily and performantly expressed in their language, and made the hackish ugly macro system to solve the edge cases... and it worked.
I really like Rust, but I haven't been paying attention for a month or so; did something change? Templates? And the macro system was...oddly limited when I tried fooling with it.
What do you use template metaprogramming for, except to compensate C++'s flaws?
(I agree with you on automatic GC and lack of generics, but not on C++'s template model in general and especially not template metaprogramming. TMP is just the most horrible, hackish way of scripting your compiler, and I've rarely, if ever found a use for it.)
Although we can wonder about how system's programming would work when you use managed languages, the reality is that as of today (2013), system's programming means low-level memory management, an almost transparent translation from code to its lower-level counterpart (which, in 2013's system's programming jargon, means the target architecture's machine code) and most importantly having as much control as possible over what your code actually does. Having garbage collection as a language feature takes away control, and system programmers won't be able to do their job with it.
It's fine to think of GC as "fast enough" in 2013, but that's when you're working on things were speed/space isn't scarce. Go might work out for Google, since their "systems" comprise of tens of thousands of computers, where reliability and maintainability are more important than latency. For the rest of us C++ coders, we'll probably won't be able to replace C++ with Go for the tasks where we need to do systems programming, simply because we on things that require us to be control freaks.
Quite frankly, this post by Rob Pike saddened me, because it seemed like he was desperately trying to counter the Go criticism with a not very well thought out rant.
The thing with Go is that it is (was?) marketed as a system's programming language. Go might work as a replacement for Java, but Java is not for system programming.
Whoever decided to say Go was capable of it either has no idea what systems programming means or was being deceitful. Go can not replace C++; these languages don't solve the same problems.