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.