It somewhat depends on what you mean by "manual memory management", I am not sure it has a definition beyond garbage collectors being outside it -- gray areas e

It somewhat depends on what you mean by "manual memory management", I am not sure it has a definition beyond garbage collectors being outside it -- gray areas exist. Using that tool requires some mastery of its idioms and rules regardless. Memory management is much more complicated than safely acquiring and releasing memory for object instantiation, or even accessing it safely. At least in C++, you can build safe memory abstractions for almost any resource model, including some pretty unusual ones that show up in performance-sensitive applications. In C it is significantly more difficult. If you are building large-scale, high-performance infrastructure, manual memory management is to some extent unavoidable. In many database engines, for example, memory lifetimes and object lifetimes are distinct and independent concepts. There are classes of algorithm optimization that require strict and explicit understanding of the address space your process claims to own. The silicon does not respect the object model of your programming language, but you still need the silicon to manipulate memory directly (as it understands it) for performance reasons. This seems complicated but understanding it well enough to leverage it has significant performance implications. That said, I don't see a lot of heap allocation in things like database engines. Almost all the memory used is allocated and deployed at bootstrap, and most of the remainder is on the stack. Not a lot of attack surface for memory management problems to show up. Other applications may be different.