Most importantly can go lang really take the place of C++
Still, you will be able to do "pretty darned well" in Go. And there's a lot of use cases for which that will be indistinguishable from the "absolute top end".
http://www.azulsystems.com/technology/java-garbage-collectio...
So yes, it is possible to have pauseless GC. That won't fit all problems that C++ is used for (like embedded), but it certainly hits on the server software side of things.
Most modern server software performance is significantly bound by memory bandwidth and latency. Introducing inefficiencies in this area tends to result in material degradation of software throughput. In fact, this is the only substantial advantage of C/C++; it can be efficient with memory access, caching, and utilization in a way that no GC language can be, and these are major contributing factors to performance.
I'd actually say quite the opposite of what you are saying: in a server environment, you often care more about throughput and mean latency (as opposed to 99th %-ile latency), and GC can really do great there. What's nice is that GC allows you to have near zero cost heap allocations and amortizes the cost of cleanup. What tends to be the problem is a lot of languages with GC make it difficult to efficiently work with the systems's buffer cache, so you typically see problems with systems that do disk I/O with large amounts of data.
I've written a LOT of C/C++ & JVM based servers. Particularly for large projects with a lot of independent moving parts and object lifecycles that are not tightly tied to sessions, the JVM based servers are remarkably competitive if they aren't disk IO bound.
There's a reason why a lot of HFT firms use Java...
C/C++ still kicks butt for tightly written servers with fairly fixed functions, and generally for anything that does tons of disk IO (though the Cassandra guys have, as an example, demonstrated one can do quite well if you take the time to get it right), and of course anything with unsigned arithmetic (seriously, when are we going to acknowledge that this was a bad idea?).
It may not be "inherent" to GC, but in practice every GC that I'm aware of has terrible cache efficiency compared to manual memory management.
> Copying collectors (like the one the HotSpot VM uses for Eden Space) tend to have great cache efficiency as compared to typical use of the C heap
False comparison. The real test is against high performance memory techniques (like memory pools, which are relatively easy and common in practice if you care at all about cache efficiency) not "typical use of the C heap." When you actually compare GC vs high performance manual memory management, manual memory management is significantly faster.
That's not a false comparison. They represent about equal development effort (well, the GC version is likely still less effort).
Sure, if you spend a ton of time optimizing your memory usage for your specific needs you will do better than a general purpose algorithm (though it is remarkable how often those solutions often implement their own forms of automatic memory management tuned for their needs). If it turns out that you couldn't do that, it'd be awfully hard to collect a paycheck (and in fact most programmers could not collect that paycheck).
Of course, even that effort would not measure up as compared to an omniscient GC algorithm (and the paycheck for building that would be even bigger ;-). What is the point?
GC's do well. When you really need to tune memory usage, you get in there and do the work, and you and do that in GC'd runtimes too. A good memory manager will, for common workloads, start you off in a better place and make the work of tuning easier. Certainly there are cases where it won't be so helpful, but that doesn't mean they are "bad" at memory cache efficiency.
Hmm. Clearly I don't know much about this. How do you turn off garbage collection in Java and (say) Python?
BS. Most languages don't allow you to turn off their GC, except if by it you mean doing silly tricks and jumping through hoops, using tons of memory to avoid having to GC, using pools of pre-allocated objects, not using any standard libs, etc. Even then, they are not callable from outside code (like C is and Rust tried to be) and memory use is huge.
"Tried"? AIUI, every part of Rust is a work-in-progress.
Pretty much every language can interoperate with C.