I care a lot about code quality and robustness. But big projects are almost NEVER done solo. Thus, your code is only as strong as the weakest developer on your team.
Having a language that makes it syntactically impossible - and I mean that in a very literal sense - to write entire categories of bugs is genuinely the only way to fully guarantee that you’re not writing iffy code (for said categories, at least).
Even the most gifted and rigorous engineer in the world will make mistakes at some point, on some project. We are humans. We are fallible. We make mistakes. We get distracted. We fuck up. We have things on our mind sometimes. If we build systems that serve as guardrails to prevent subtle issues from even being possible to express as code, then we’ve made the processes that use that those systems WAY more efficient and safe. Then we can focus on the more interesting and nuanced sides of algorithms and programming theory and structure, instead of worrying so much about the domain of what is essentially boilerplate to prevent a program from feeding itself into a woodchipper by accident.
And that’s why we make sure to double check our work.
Even in C++, most of the times, we are using logically managed containers. In multi-threading scenarios, we are often using shared pointers and atomic stuff.
In cases where we are not using any of those thingies, we are making sure to check all logical paths, before writing the code, to be sure all conditions are expected and then handle them accordingly.
Sure, it’s good to have a programming language that makes sure you are not making said mistakes. And then you can keep your mind on the business logic.
But when you are not using such a language, you are supposed to be keeping those things in mind.
So you will need to add to that: “We are lazy. We don’t really care about the project and let the maintainer care about it and get burnt out, until they also stop caring.”
I really don’t think you’re looking at this from the right angle. This isn’t about being lazy. This isn’t about not double checking work.
My point is that statistically speaking, even the double checkers who check the work of the double checkers may, at some point, miss some really subtle, nuanced condition. Colloquially, these often fall under the category of critical zero-day bugs. Having a language that makes it impossible to code that’s vulnerable to whole categories of exploits and bugs is an objective good. I’m a bit mystified why you’re trying to argue that it’s purely a skill/rigor issue.
Case in point: the LN-100 inertial nav unit used in the F-22 had a bug in it that caused the whole system to unrecoverably crash as the first squadron flew over the International Date Line as it was being deployed to Kaneda air base in Japan. The only reason why they didn’t have to ditch in the pacific was that the tanker was still in radio range; they had to be shepherded back to Honolulu by the tanker, and Northrop Grumman flew an engineering team out to (very literally, heh) hotfix the planes on the tarmac, and then they continued on to Kaneda without issue. TLDR: even with systems that enforce extreme rigor (code was developed and tested under DO-178B), mistakes can and do happen. Having a language that guards against that is just one more level of safety, and that’s a good thing.
Having a language that guards against that is just one more level of safety, and that’s a good thing.
Yes it is.
But my point simply is, “caring” about stuff needs to be normalised, instead of over-anti-pedantism and answering concerns with stuff like, “chill dude!”.
We know very well that not all bugs are memory related.
That’s really not how software development works.
I care a lot about code quality and robustness. But big projects are almost NEVER done solo. Thus, your code is only as strong as the weakest developer on your team.
Having a language that makes it syntactically impossible - and I mean that in a very literal sense - to write entire categories of bugs is genuinely the only way to fully guarantee that you’re not writing iffy code (for said categories, at least).
Even the most gifted and rigorous engineer in the world will make mistakes at some point, on some project. We are humans. We are fallible. We make mistakes. We get distracted. We fuck up. We have things on our mind sometimes. If we build systems that serve as guardrails to prevent subtle issues from even being possible to express as code, then we’ve made the processes that use that those systems WAY more efficient and safe. Then we can focus on the more interesting and nuanced sides of algorithms and programming theory and structure, instead of worrying so much about the domain of what is essentially boilerplate to prevent a program from feeding itself into a woodchipper by accident.
And that’s why we make sure to double check our work.
Even in C++, most of the times, we are using logically managed containers. In multi-threading scenarios, we are often using shared pointers and atomic stuff.
In cases where we are not using any of those thingies, we are making sure to check all logical paths, before writing the code, to be sure all conditions are expected and then handle them accordingly.
Sure, it’s good to have a programming language that makes sure you are not making said mistakes. And then you can keep your mind on the business logic.
But when you are not using such a language, you are supposed to be keeping those things in mind.
So you will need to add to that: “We are lazy. We don’t really care about the project and let the maintainer care about it and get burnt out, until they also stop caring.”
I really don’t think you’re looking at this from the right angle. This isn’t about being lazy. This isn’t about not double checking work.
My point is that statistically speaking, even the double checkers who check the work of the double checkers may, at some point, miss some really subtle, nuanced condition. Colloquially, these often fall under the category of critical zero-day bugs. Having a language that makes it impossible to code that’s vulnerable to whole categories of exploits and bugs is an objective good. I’m a bit mystified why you’re trying to argue that it’s purely a skill/rigor issue.
Case in point: the LN-100 inertial nav unit used in the F-22 had a bug in it that caused the whole system to unrecoverably crash as the first squadron flew over the International Date Line as it was being deployed to Kaneda air base in Japan. The only reason why they didn’t have to ditch in the pacific was that the tanker was still in radio range; they had to be shepherded back to Honolulu by the tanker, and Northrop Grumman flew an engineering team out to (very literally, heh) hotfix the planes on the tarmac, and then they continued on to Kaneda without issue. TLDR: even with systems that enforce extreme rigor (code was developed and tested under DO-178B), mistakes can and do happen. Having a language that guards against that is just one more level of safety, and that’s a good thing.
Yes it is.
But my point simply is, “caring” about stuff needs to be normalised, instead of over-anti-pedantism and answering concerns with stuff like, “chill dude!”.
We know very well that not all bugs are memory related.
Even this article of the thread states it dropped from 76% to 24% through the introduction of Rust.
If you seriously think:
I’d like to see the water you walk on.
Anti Commercial-AI license
I definitely thing that.
The rest, not so much.