If anything, Rust shows that you can have reliable "manual" memory management without the need for a GC. The best of both worlds. While I don't buy the GC per

If anything, Rust shows that you can have reliable "manual" memory management without the need for a GC. The best of both worlds. While I don't buy the GC performance argument, it's ok to use it, because most of the time it doesn't matter. Sure it can be "almost as good as" manually managing memory, but that's about as hard to achieve as manually managing your memory. The point of GC is that it relieves the programmer of caring about managing memory, and as such it's only really useful where the system has sufficient resources that the fact that a GC is running doesn't matter. For the vast majority of workloads on modern hardware this is true. At the other end of the scale, in real high-performance embedded systems, even malloc+free is too slow, and memory fragmentation is too much of a problem for things with expected uptimes measured in years. GC is a complete non-starter here. Instead these systems use pools of fixed-size buffers than can be O(1) allocated and freed, and never fragment. You can use MRU allocation of buffers from these pools to keep the dcache warm, and you can make your memory-using operations queue until they can reserve the memory they're going to use up front so that your system can run flat out using all the memory it can without ever crashing from OOM. Both malloc+free and GC (especially GC) can only dream of those characteristics.