>The perception that manual memory management is difficult to do, difficult to do correctly, and thus inherently bug-prone and unstable is common.
Yes, not just the perception. Microsoft and Google did large enough studies with the highest paid engineers in the world and they came to that conclusion. There's evidence behind it.
After working with C and C++ for over a decade, I still have to see a non-trivially sized/non-hobby project, that didn't have a vast amount of memory management bugs discovered later, with a lot of compute time for tooling and manual debugging involved.
I'd say a single talented programmer can manage memory manually mostly correctly.
But not a group of programmers of varying levels, as you will always find them in a larger project.
>If there is no organizing principle around managing these relationships and their corresponding lifetimes, through a number of subtle mistakes
Here the author seems to almost grok this. The only realization missing is that if you're not the dictator of this project, you won't be able to enforce your style top-down and this mess is almost inevitable.
Of course allocation and deallocation is also not the only memory management issue. The author seems to ignore mutability issues, array out of bounds issues, etc. which are also memory management issues C doesn't help you with. Quite often worse than a memory leak.
Despite his ranting detracting from the main point of the article, I think it's quite a solid introduction to arena allocation.
I've found it quite useful in hard real-time systems where you need more than the usual stack memory for dynamically sized arrays (within bounds).
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
