Unless the poster was including ARC-style systems in what they meant by "garbage collection".

Ideally you want something that is both deterministic (i.e., it's not running randomly in the background like a traditional GC) and that guarantees there are no leaks. In theory ARC gives you both of these.

ARC depends on malloc/free which isn't quite as deterministic as you make it out to be - precisely because malloc/free does not (typically) run in the background, it needs to update internal datastructures when it gets the chance, which can lead to considerable latency spikes.

In fact, I'd go so far as to say latency isn't the issue - the issue is that typically GC'd languages rely heavily on heap allocation because it's cheaper(!) not more expensive. Put another way: java creates lots of garbage, C/C++ does not.

If you wrote a C/C++ program that allocated as heavily as a typical java program... well, I'd expect performance issues that would probably be worse than java's.

True, any malloc (or new) and any free (or delete) is non-deterministic (unless you're using a placement allocator). But GC isn't better, because the new still has the same non-determinism, Also, the GC has to do more work than a programmer-controlled delete (walking data structures for liveness, or something approximately equally expensive), and tends to do both the walking and the deletes in bursts. But...

> java creates lots of garbage, C/C++ does not.

Properly written C/C++ does not. Badly written C/C++ creates garbage (leaks memory), and it can never be recovered, because there's no GC. The solution isn't GC, though - it's to pay more attention to who owns the memory.