The thing they rewrote also worked great in production.
And fuzzing originated in C / C++ tools and is available for them as well, probably more diverse and mature than what is available in Rust.
The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing.
Which Rust evangelists find difficult to acknowledge because security is that one thing that Rust has going for it.
So difficult that you would rather try to misdirect than to acknowledge that software written in Rust will crash. And when processing arbitrary user output, it'll crash badly when not written with care and fuzzed a lot. Kind of like C++.
> The thing they rewrote also worked great in production.
It didn't for them, that's why they rewrote it.
> Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing.
By whom? I don't think memory safety bugs are the only class of bugs, and neither do you, so who are you arguing against?
> Which Rust evangelists find difficult to acknowledge because security is that one thing that Rust has going for it.
Hard disagree. Rust also offers a solid type system, pain-free dependency management and all-around good tooling, just to name a few. It's much more than a "memory-safe C++" or whatever.
> And when processing arbitrary user output, it'll crash badly
If your definition of "badly" is "at a well-defined point, without any memory corruption", sure. But even here memory safety prevents what could be a much more painful debugging experience.
> The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing.
There are straw men and then there are straw man armies. This is probably the biggest one I've seen yet.
Ohh, I got one. Rust is less secure than C++ because it causes people to be overconfident in its security properties. The sharp edges of C++ are a feature that cause people to focus on correctness, not just get it for free.
You jest, but that used to be an argument against making seatbelts mandatory in cars. I suppose people would drive even more safely if there was a sharp metal spike sticking out of the center of the steering wheel.
This assumes that each person is responsible for their own safety. But you have no control over the other guy that puts people at risk. By mocking it, maybe we can prevent this form of argumentation earlier?
Hopefully in 20 years or less we will see unsafe code in the same way we view leaded gas, cigarettes and CO2. The other thing I realized in the last couple years is that eventually, everything becomes safety critical to someone at some point. That if you think you have to just protect this one system but that others can fail, is flawed on large scales. You can't tractably realize the failure graph, and nor can you prevent a seemingly innocuous thing from being used in a critical way.
The pandemic was a great lens into how human resilience kept flawed systems functioning in a way that few realized were flawed. The pharmacies in my area are still recovering only to have their problem exacerbated by more rigid controls that prevent local autonomy from making the system resilient. In this particular case, automation has made a problem worse by preventing humans from doing the little local silent repairs that they were previously doing.
The great (unintentional?) irony of that argument is that before seatbelts, that was arguably how cars used to be manufactured. Back then, drivers were often killed in car crashes by being impaled on the steering wheel. Those in the passenger seat would die from being hurled through the window. Despite the elevated risk in those older cars, drivers weren't safer --- they were unsafe to such a degree that it formed the argument for mandating seat belts in the first place.
Is it? For bicycle helmets I just know these variants:
1. Wearing a bicycle helmet is unpleasant, so people will cycle less and possibly use other modes of transportation such as cars. The risk of a traumatic head injury may decrease but this is offset either partially or fully by other health risks such as obesity.
2. Other road users in heavier vehicles (e.g. cars) perceive riders wearing bicycle helmets as less vulnerable, and so keep less distance when overtaking them, thus wearing a helmet increases the risk of collision.
I don't think I've ever heard someone say they won't wear a bicycle helmet because it would make them personally drive more dangerously.
I personally strongly oppose mandatory bike helmets. I think one of the reasons so many people own and ride bikes in my country (The Netherlands) is that we don't have mandatory helmets. Making helmets mandatory for people inside cars would also prevent or reduce head injuries (and indeed that is why they are worn by race car drivers) so if we ever introduce mandatory bicycle helmets here perhaps we can introduce mandatory car helmets at the same time, to ensure that people won't just take a car instead.
> The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing.
You know, I'm a Rust evangelist. And I can tell you, why I ignore logic bugs when trying to sell Rust. Rust can prevent some logic bugs if they break invariant you managed to encode or enforce in your types. But it is a difficult topic to dive in a internet discussion. The best I could do is to bring some anecdotal data points, like &str being guaranteed to contain only valid utf8 strings. The worse issue (for a discussion) that it may be not obvious what kind of a logic error can be fixed by the type invariant discussed. So to show it I need to find some more examples of bugs that were prevented by enforcing the invariant. But you see, bugs that were prevented were not documented. It goes like this: you write code, it doesn't compile because rustc is unhappy, you fix code and it compiles nice now, you call it a day and move along. When you fixed this small issue it was not a bug, just one of a several complaints of rustc. You would need to speculate a lot about what could happen bad if rust allowed this issue to live.
We can try to get to the point from a different angle and to find logic errors in a wild, and then to speculate how type invariants might prevented them if programmers had written their types in a some particular way. But it raise a question: would they write their types in this way before they faced this particular logic error?
If I tried to talk about complex relationships of Rust and logic errors, I would need to dive into an ocean of speculations. Rust deniers are not very cooperative on this regard, and I'd bet they would just dismiss all the speculations as... well... speculations. And they would keep insist that if we cannot measure a falling frequency of logic bugs, then it is all immaterial. Some even go further and claim that if some tool doesn't prevent all bugs of a kind, then it is a useless thing.
So it is not a fun to talk about logic errors with rust deniers. Among rust evangelists the talk doesn't happen either, because they do not split bugs into two categories "logic" and "memory" bugs, they split them into "can be prevented by type invariant" and "cannot be prevented by type invariant, or too f*king difficult to". They talk about memory safety to laymen because it is something that laymen understand and it doesn't need explaining. And Rust can prevent all the bugs of this kind, so even when we talk to a people who thinks in black-and-white, we can make statements that are defensible in this Aristotelian tradition of excluded middle.
> Creusot works by translating Rust code to WhyML, the verification and specification language of Why3. Users can then leverage the full power of Why3 to (semi)-automatically discharge the verification conditions!
Great example of the kind of cherry picking in these conversations. It is insincere and uncharitable, all you did was show your colors. Didn't say everything was exclusive to Rust, while you make no mention on the ground breaking work in CreuSAT. Given as an example of the kinds of things besides memory lifetime tracking that can make Rust code more robust against logical errors.
> Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing.
I don't think that's true. Sure, there are zealots who oversell things, but reasonable people (including those who are actual leaders in the Rust community) are realistic about the classes of bugs that Rust eliminates, as well as those Rust doesn't help with.
Rust is interesting in that if you really thought it was magical safety across all bugs, you're probably not smart enough to compile a real application, let alone actually have read enough documentation to do more than a hello world.
What you said, although I would have probably phrased it less harshly :)
But yes, my point was that there are a lot of enthusiastic articles about how Rust can prevent "whole classes of bugs", which mostly gloss over the fact that there are other classes of bugs that it doesn't prevent. Of course this doesn't mislead experienced developers, but I'm not so sure about novices or less technically inclined people.
It seems like it is true and accurate to say that Rust prevents “whole classes of bugs”. It is obvious that other bugs can still exist. Otherwise people would say Rust prevents “all bugs”.
Are you disappointed that Rust evangelists don’t spend time talking about the fact that bugs can exist in Rust programs? Did you see the two articles posted in the last week alone about bugs that were found in Rust code? They reached the front page of HN
which mostly gloss over the fact that there are other classes of bugs that it doesn't prevent
That's nothing more than a technically-dressed version of whataboutism, isn't it? Or can you show other languages that do prevent those other unnamed classes of bugs?
Er... no. I was simply saying that the many articles about how reliable Rust is and how many bugs it catches for you might lead to a false sense of safety. Nothing more, nothing less.
What's the use of standing on that anti-static mat and wearing that grounding strap? Can't you see there are fork lifts zipping around just right in the next room? That mat is giving you a false sense of security!
And fuzzing originated in C / C++ tools and is available for them as well, probably more diverse and mature than what is available in Rust.
The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing.
Which Rust evangelists find difficult to acknowledge because security is that one thing that Rust has going for it.
So difficult that you would rather try to misdirect than to acknowledge that software written in Rust will crash. And when processing arbitrary user output, it'll crash badly when not written with care and fuzzed a lot. Kind of like C++.