> it's easy to visually confirm everything is cleaned up.
Yes and no.
It's easy to not make a mistake in a function. It's basically impossible to not make this mistake in 1'000 functions.
Especially as code evolves over time, being 99% perfect about this, or even 99.9% perfect, is just not good enough. Not nearly enough.
And this reminds me of something Schneier said, that everyone can make a cryptographic algorithm that they themselves cannot break. That even as a professional, having your algorithm broken is not even embarrassing.
Similarly, very good coders are not even embarrassed when they fail at memory management. People may be better or worse at it, but even the best of us are terrible at it.
I once knew a very good coder who bragged about how apparently he's the only one able to write code that's not buggy like this.
To prove a point, I spent an hour reading his opensource project and found several resource leaks, at least one of which was remotely triggerable.
It's easy to do it right once, usually, but no these mistakes happen all the time.
> if I find [… typo words(?) omitted … ] a leak in the code I usually refactor to make the correctness more obvious.
This seems to contradict that it was easy to avoid in the first place. Yes, refactor can help. But there's a bit of learned helplessness, in that this is actually the language's fault, and it doesn't have to be that way.
> To prove a point, I spent an hour reading his opensource project
> and found several resource leaks
Sounds like some interesting case studies. Could you share some?
> > if I find [… typo words(?) omitted … ] a leak in the code I
> > usually refactor to make the correctness more obvious.
I should rewrite this as - if I find a leak that I accidentally introduced, I will refactor in the process of correcting it, to make the mistake harder to repeat and the correctness easier to confirm.
There are non-language mechanisms that help code run safely, like Wasm, which is a sandbox. Also msan and asan should be used more.
Thinking that changing the language is the right way to fix all the problems you mentioned still seems like a premature assumption. The fact that 100% perfection is worth pursuing at all costs is theoretical and you could be losing things more valuable in the process - e.g. FFI bindings suck, and the added fragmentation in having so many languages in the craft is a pernicious cost with a multitude of aspects to it.
Can't be more specific without doxing myself, I'm afraid.
There are non language ways to make things safer, sure. Take C++, one can do things other than RAII to avoid resource leaks, and it'll be a good pattern. But RAII is right there.
In C++ one can be disciplined about object ownership. But I find that in Rust "doing the right thing" is not optional.
Static and strong typing have similar virtues.
You can write fine software in assembly. Steve Gibson apparently does.
I'm not saying there are any silver bullets. I do appreciate that five minutes spent now being forced to think about object ownership, can save a six month project down the line refactoring to remove all shared_ptrs.
Not accidentally creating copies, because RVO has many conditionals on when it happens.
No silver bullets. But in my opinion C is always worse than at least a C++ subset deliberately chosen. Plain C is because you enjoy the journey, not because you'll get there faster or better.
In C++ you can refactor to RAII encapsulate, when a resource is leaked. In C you can't.
> To prove a point, I spent an hour reading his opensource project
> and found several resource leaks
This is asking a lot, but if you enjoy that, I would be thrilled if you could do the same for some of my C projects - nusort and werm under github.com/matvore.
Yes and no.
It's easy to not make a mistake in a function. It's basically impossible to not make this mistake in 1'000 functions.
Especially as code evolves over time, being 99% perfect about this, or even 99.9% perfect, is just not good enough. Not nearly enough.
And this reminds me of something Schneier said, that everyone can make a cryptographic algorithm that they themselves cannot break. That even as a professional, having your algorithm broken is not even embarrassing.
Similarly, very good coders are not even embarrassed when they fail at memory management. People may be better or worse at it, but even the best of us are terrible at it.
I once knew a very good coder who bragged about how apparently he's the only one able to write code that's not buggy like this.
To prove a point, I spent an hour reading his opensource project and found several resource leaks, at least one of which was remotely triggerable.
It's easy to do it right once, usually, but no these mistakes happen all the time.
> if I find [… typo words(?) omitted … ] a leak in the code I usually refactor to make the correctness more obvious.
This seems to contradict that it was easy to avoid in the first place. Yes, refactor can help. But there's a bit of learned helplessness, in that this is actually the language's fault, and it doesn't have to be that way.