Hacker News Reader

Comment by mk89 | Hacker News Reader

I didn’t say it’s not an improvement. I just wonder who will you blame once you have a hacker exploiting that exact CVE which you didn’t know about because they sold you rust as memory safe language, so you didn’t take the time to run any sanitizer or similar.

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.

View on HN

> I didn’t say it’s not an improvement.

You… almost literally did?

> I am happy that we are moving towards a future where there are less memory bugs, but… are we really?

> You… almost literally did?

I don't understand this comment, to be honest. What does it add to the conversation?

Why shouldn’t this kind of inconsistency be pointed out?

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.

You might be right, it's probably just easier to ask :)

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.

In my experience, almost no Rust programmers believe that it's a silver bullet that results in 100% safety. Certainly orders of magnitude fewer people than people seem to believe exists.

What it does do is drastically cut down the number of places you have to deeply audit.

Rust would have prevented about half of the CVEs in C code (I've seen a few different studies with somewhat different results, half is close enough for discussion). The other half is on you to write good code.

Note that the half Rust would prevent tends to be less impactful, still a CVE, but the exploit is less impactful to end users.

If we leave it to the programmer, what are we improving?

We did a big improvement, but why can’t we disable “unsafe”?

That would leave absolutely no margin for such errors.

> We did a big improvement, but why can’t we disable “unsafe”?

Because there are things which literally can not be safe, and rust will not let you get away with pretending.

> 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?

Rust has a culture where people don't use `unsafe` unless absolutely necessary. That is generally good enough in my experience.

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

https://github.com/rust-secure-code/cargo-geiger

https://github.com/crev-dev/cargo-crev

> If you want to go further, you can disable unsafe in a crate by adding #[forbid(unsafe)].

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?

> 1) Don't allow unsafe (you can have an easy code search for this) 2) Forbid unsafe cargos

This can be accomplished with cargo vet (https://mozilla.github.io/cargo-vet/how-it-works.html?highli...)

Unsafe is necessary for Rust to meet its goal of being a systems language. If Rust didn't provide unsafe, then Rust programmers would be forced write this code in C, which would be just as unsafe, but a worse developer experience.

There is a time when you need unsafe. Hopefully those are rare, but most rust projects will need it. (remember Rust is aiming for systems programming, some domains never need unsafe, but others will need it).

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.

> most rust projects will need it.

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.

I'm biased here because I work in embedded where I can't see any way to write code that directly interacts with hardware without unsafe. There are other world out there that I don't know much about.

Reply on news.ycombinator.com