> It could appear that these results undermine the belief that Rust safety model represents an improvement over other languages, e.g. C++, but this would not be correct, say the researchers behind Rudra, who still consider Rust safety a supreme improvement.
They found ~100 security issues in 45k packages. That's clearly better than C++.
Does Rust provide a way to check if you’re using unsafe code? What if I want to disable that? If I need to make a mission critical software I need to be aware of what I am deploying. If on the other hand we want Rust to be the new JS for backend, then yes so be it, we improved over c++, well done.
You… almost literally did?
> I am happy that we are moving towards a future where there are less memory bugs, but… are we really?
I don't understand this comment, to be honest. What does it add to the conversation?
I’m happy to believe GP didn’t say exactly what they intended to or simply misremembered what exactly they said previously. It’s certainly something I’ve done before in an online conversation. And when it’s happened to me I’ve appreciated having it pointed out explicitly so I could clarify what my thoughts actually were. Often it’s because I misstated my opinion without realizing.
Either that’s the case here (what I’m choosing to believe) and it gives GP an opportunity to explain further or GP is engaging in this discussion in bad faith. In either case, I don’t see the downside.
So, when I wrote the message I was really physically and mentally tired, I wrote from the phone which unfortunately doesn't always help me write 100% consistent sentences.
Finally I just used wrong wording. As I mentioned in another comment, the improvement is clear and it's the new way forward. In my opinion it simply doesn't solve all memory safety issues, and while with c and c++ you know unfortunately what you get, with Rust or Swift you might get a false sense of 100% safety where there is not.
What it does do is drastically cut down the number of places you have to deeply audit.
Note that the half Rust would prevent tends to be less impactful, still a CVE, but the exploit is less impactful to end users.
We did a big improvement, but why can’t we disable “unsafe”?
That would leave absolutely no margin for such errors.
If you want to go further, you can disable unsafe in a crate by adding #[forbid(unsafe)].
And if you need more control than that, there's probably tooling out there that will help depending on what exactly you need.
https://github.com/rustsec/rustsec/tree/main/cargo-audit
Cool, so it's possible to exclude dependencies which include unsafe stuff! That's awesome.
See, this is the kind of stuff I was looking for.
From the perspective of a team writing new Rust code:
1) Don't allow unsafe (you can have an easy code search for this) 2) Forbid unsafe cargos
Finally: how do you catch unsafe in the standard library?
This can be accomplished with cargo vet (https://mozilla.github.io/cargo-vet/how-it-works.html?highli...)
Because there are things which literally can not be safe, and rust will not let you get away with pretending.
Can you post maybe a good article explaining this?
I'm a c++ guy interested in Rust, my understanding is Unsafe lets me design custom high performance interfaces that do weird pointer tricks (which is needed to interface to the C and C++98 interfaces I work with), and it is on me to bounds check. Then the users of my interface don't use unsafe because I did all the nasty parts and their code is easy to write well.
If you mean "writing unsafe in your codebase yourself," this isn't borne out by the numbers.
If you mean "depending on unsafe somewhere in your dependencies" then 100% of Rust code needs unsafe, just like any other language. Interacting with hardware, many operating systems' APIs, these aren't created in a way to guarantee it, and you need to interact with them to do anything.