The Go authors are saying that Go is for "systems programming". What they apparently mean by that is server side infrastructure stuff, the kind that is now frequently written in Java. Things like Hadoop, Tomcat or even database systems.
What they don't mean (I believe) is operating systems, device drivers, embedded systems, real time stuff including many trading and telecoms systems, graphics pipelines, signal processing, libraries that are too complex to rewrite in every language (like browser engines), etc. There's a very long tail of these things and it's growing as we get more intelligent connected devices.
Much of that is now written in C++. The question is, will C come back to replace C++? I don't think that's going to happen. I love C. It was my first language and I admire its simplicity. But there is one thing that C++ has over C: RAII. RAII is an ingenious universal resource management tool that gives us 90% of the productivity gains we get from garbage collection without any of the unpredictability, and it helps with resources other than memory as well.
Forget templates and all that fancy stuff. C++s raison d'etre is RAII. So, I think, Rust may have a chance to replace C++ (purely from a technological perspective) but Go unfortunately does not.
Only future will tell.
I have used in the past desktop operating systems (Native Oberon and AOS) without any single line of C++ code, written in GC aware system programming languages (Native Oberon and Active Oberon).
I do like C++ a lot, but I am quite confident that manual memory management will eventually be a sweet memory of old coders.
I don't mean that Go will be that language per se, but that whatever we might use for doing systems programming in future OSs will be GC enabled, even if it allows for some way to do unsafe/system local memory management.