One of the first claim of the article is plainly false. Static allocation does not avoid use-after-free. It just avoids accessing freed memory. You can still ha

One of the first claim of the article is plainly false. Static allocation does not avoid use-after-free. It just avoids accessing freed memory. You can still have bugs and access dead data in those static arrays that are really dead object but your buggy code still references and access them. Most benefits listed have nothing to do with memory allocations. For example "having a client open too many connections" can be limited by... limiting the number of open connections. Where and how that check is done might differ, but it's not related to memory allocations. There are BIG downfalls to static allocations: - You cannot support varied workloads. If one workload needs a lot of X and another needs a lot of Y, well, you already decided the maximum numbers of X and Y and cannot re-balance it. - If you run out of anything you thought was "sufficient" enough, your programs just fails. And I know, because I've worked on program that did static initialization at startup, and they failed in just that way. I also did test the performance benefits: it was around 12%. So you do get some performances out of it, but the added complexity of having things fail out where in a normal program it would just chug along, having to deal with these failures and the usual have-to-roll your-own data structures or libraries is not worth 12%. Because, remember, if you go out of your way to have static allocations, that means all 3rd-party libraries have to do it too, otherwise the benefits is wasted. Is that worth 12%? IMO, no. I mean, sure, your program is easier to analyze statically, just like if you gave up dynamic threads and instead just pin different parts of your program to different CPU core. Sure that solves some concurrency problems, but most programs don't do this for obvious reasons.