The thing about Java is that it is really hard to write clever hard to maintain code in it. Sure, it makes it painful to develop with, but because it leads to maintainable code the code never gets thrown out and rewritten and almost by accident very large multi-million line code bases grow over time in it. These huge code bases lead to a lot of jobs for people doing maintenance on them, not because developers like the language, but because the code still works and never becomes impenetrable, as most large code bases often do.
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.
A lot of "dependency injection" BS can also exceed the tolerance threshold of more experienced programmers.