• 0 Posts
  • 1.61K Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle




  • 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 even compile 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.


  • 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.














  • Heh, we’re still on the X-Y problem to a degree.

    I’d recommend another top-level reply to your post, or a new post, describing precisely how your hardware and ZFS pools are set up, alongside a description of the firmware/stability issues you’re seeing, and solutions you’ve tried already. We’re a bit far down a comment chain at the moment, so you’ll probably get more engagement that way. Not trying to be an ass - this actually sounds like an interesting (and, I’m sure, obnoxious) problem. Putting all the cards on the table will help people give you a more complete answer more quickly.