> The problem with this statement is that without a memory safety invariant your code doesn't compose
Yes, but that holds for any correctness property, not just the 0.0001% of them that memory safe languages guarantee. That's why we have bugs. The reason memory safety is a focus is because out-of-bounds access is the leading cause of dangerous vulnerabilities.
> The goal of all engineering disciplines, including software, should be a minimization of errors and defects.
Yes, but practical minimisation, not hypothetical minimisation, i.e. how can I get the least bugs while keeping all my constraints, including budget. Like I said, a language like Rust exists because minimisation of errors is not the only constraints, because if it were, there are already far more popular languages that do just as much.
> You'll notice a stark contrast between Engineering and Computer Tech.
I'm not sure I buy this, because physical, engineered objects break just as much as software does, certainly when weighted by the impact of the failure. As to learning our lessons, I think we do when they are actually real. Software is a large and competitive economic activity, and where's there's a real secret to more valuable software, it spreads like wildfire. For example, high-level programming languages spread like wildfire; unit tests and code review did, too. And when it comes to static and dynamic typing, the studies on the matter were inconclusive except in certain cases such as JS vs TS; and guess what? TS has spread very quickly.
The selective pressures are high enough, and we see how well they work frequently enough that we can actually say that if some idea doesn't spread quickly, then it's likely that its impact isn't as high as its fans may claim.
> And how do programmers react to it? With disgust and a desire for less safety.
I don't think so. In such a large and competitive economic activity, the assumption that the most likely explanation to something is that the majority of practitioners are irrational seems strange to me. Rust has had some measure of adoption and the likeliest explanation for why it doesn't have more is the usual one for any product: it costs too much and delivers too little.
Let's say that the value, within memory safety, between spatial and temporal safety is split 70-30; you know what? let's say 60-40. If I can get 60% of Rust's value for 10% of Rust's cost, that a very rational thing to do. I may even be able to translate my savings into an investment in correctness that is more valuable than use-after-free.
> Yes, but practical minimisation, not hypothetical minimisation, i.e. how can I get the least bugs while keeping all my constraints, including budget. Like I said, a language like Rust exists because minimisation of errors is not the only constraints, because if it were, there are already far more popular languages that do just as much.
Rust achieves practical minimization, if not outright eradication, of a set of errors even in practice. And not just memory safety errors.
> Like I said, a language like Rust exists because minimisation of errors is not the only constraints, because if it were, there are already far more popular languages that do just as much.
The reason Rust exists is that the field hasn't matured enough to accept better engineering practices. If everyone could write and think in pre/post/invariant way, we'd see a lot fewer issues.
> I'm not sure I buy this, because physical, engineered objects break just as much as software does, certainly when weighted by the impact of the failure.
Dude, the front page was about how Comet AI browser can be hacked by your page and ordered to empty your bank account. That's like your fork deciding to gut you like a fish.
> the assumption that the most likely explanation to something is that the majority of practitioners are irrational seems strange to me.
Why? Just because you are intelligent doesn't mean you are rational. Plenty of smart people go bonkers. And looking at the state of the field as a whole, I'd have to ask for proof it's rational.
> Rust achieves practical minimization, if not outright eradication, of a set of errors even in practice. And not just memory safety errors.
It achieves something in one way, while requiring you to pay some price, while other languages achieve something in a different way, with a different cost. I've been involved with software correctness for many, many years (early in my career I worked on safety-critical, hard realtime software, and then practised and taught formal methods for use in industry), and there is simply no research, none, suggesting that Rust's approach is necessarily the best. Remember that most software these days - not the kind that flies aeroplanes or controls pacemakers, that's written mostly in C, but the kind that runs your bank, telecom supplier, power company, healthcare etc. but also Facebook - is written in languages that offer the same guarantees as Rust, for better or worse.
> If everyone could write and think in pre/post/invariant way, we'd see a lot fewer issues.
Except I've worked with formal methods in a far more rigorous way than Rust offers (well, it offers almost nothing), and in this field there is now the acknowledgement that software correctness can be achieved in many different ways. In the seventies there was a consensus about how to write correct software, and then in the nineties it all got turned around.
> That's like your fork deciding to gut you like a fish.
I don't think so, because everyone uses a fork but this is the first time I hear about Comet AI. The most common way to empty people's bank accounts is still by conning them.
> Why? Just because you are intelligent doesn't mean you are rational.
Intelligence has nothing to do with it. But "rational" here means "in accordance with reality", and since software is a major competitive economic activity, which means that if some organisations act irrationally, there's both a strong motivation and an ability to take their lunch money. If they still have it, they're probably not behaving irrationally.
Yes, but that holds for any correctness property, not just the 0.0001% of them that memory safe languages guarantee. That's why we have bugs. The reason memory safety is a focus is because out-of-bounds access is the leading cause of dangerous vulnerabilities.
> The goal of all engineering disciplines, including software, should be a minimization of errors and defects.
Yes, but practical minimisation, not hypothetical minimisation, i.e. how can I get the least bugs while keeping all my constraints, including budget. Like I said, a language like Rust exists because minimisation of errors is not the only constraints, because if it were, there are already far more popular languages that do just as much.
> You'll notice a stark contrast between Engineering and Computer Tech.
I'm not sure I buy this, because physical, engineered objects break just as much as software does, certainly when weighted by the impact of the failure. As to learning our lessons, I think we do when they are actually real. Software is a large and competitive economic activity, and where's there's a real secret to more valuable software, it spreads like wildfire. For example, high-level programming languages spread like wildfire; unit tests and code review did, too. And when it comes to static and dynamic typing, the studies on the matter were inconclusive except in certain cases such as JS vs TS; and guess what? TS has spread very quickly.
The selective pressures are high enough, and we see how well they work frequently enough that we can actually say that if some idea doesn't spread quickly, then it's likely that its impact isn't as high as its fans may claim.
> And how do programmers react to it? With disgust and a desire for less safety.
I don't think so. In such a large and competitive economic activity, the assumption that the most likely explanation to something is that the majority of practitioners are irrational seems strange to me. Rust has had some measure of adoption and the likeliest explanation for why it doesn't have more is the usual one for any product: it costs too much and delivers too little.
Let's say that the value, within memory safety, between spatial and temporal safety is split 70-30; you know what? let's say 60-40. If I can get 60% of Rust's value for 10% of Rust's cost, that a very rational thing to do. I may even be able to translate my savings into an investment in correctness that is more valuable than use-after-free.