As someone who has been designing, writing, and operating high-performance systems for decades, I can guarantee you that it does not boil down to "laziness".
Everyone starts with the best of intentions. malloc() and free() pairs. Then inevitable complexity comes in - the function gets split to multiple, then across modules, and maybe even across systems/services (for other shareable resources).
The mental overhead of ensuring the releases grows. It _is_ hard, and that's most definitely not a lie beyond any trivial implementation.
Surprisingly "just design systems that manage their memory correctly", as you said, is a very legitimate solution. It just so happens that those systems need good language support, to offload a good chunk of the complexity from the programmer's brain to the machine.
No, it is laziness, at the system architecture level. I've been doing this for decades too, in major corporations, writing the big name services that millions to billions of people use. The system architects are lazy, they do not want to do the accounting - that is all it is, just accounting of the resources one has and their current states, integrating that accounting tracking system into the environment - but few to none do, because it creates hard accountability, which they do not want. A soup of complexity is better for them, it grows their staff.
I've been playing this game long enough to see the fatal flaws built in, which grows complexity, staff, and the magnitude of the failures.
> I've been playing this game long enough to see the fatal flaws built in, which grows complexity, staff, and the magnitude of the failures.
Renee Descartes, a brilliant philosopher and scientist always used to say that if he thinks A and the rest of the world thinks B, the wrong one is probably him. And he was one of the most brilliant humans we've ever produced!
Mind you, don't misread that as "you should act like a sheep" but in the opposite sense, that even if you're 100% certain others are wrong, you should still have the mental acumen to understand that probability isn't stacked in your favour.
People aren't burning their professional (or even hobby) time for years or decades working on tooling and languages that help in memory management just to help other's skill issues.
They find it an issue that needs better solutions, and that's it in C.
Everyone starts with the best of intentions. malloc() and free() pairs. Then inevitable complexity comes in - the function gets split to multiple, then across modules, and maybe even across systems/services (for other shareable resources).
The mental overhead of ensuring the releases grows. It _is_ hard, and that's most definitely not a lie beyond any trivial implementation.
Surprisingly "just design systems that manage their memory correctly", as you said, is a very legitimate solution. It just so happens that those systems need good language support, to offload a good chunk of the complexity from the programmer's brain to the machine.