Does Rust programming language practically provide 'memory safety', as they say? Or it is just in theory?
Any Rust lang experters here?

@EdwardTorvalds there kinda is two different languages inside of rust: safe rust and unsafe rust. If you only ever use the first one, yes it totally provides memory safety (unless there is a bug in the compiler that lets an invalid program be compiled). I have never seen a safe rust program with memory issues (other than reference cycles, the compiler can't detect them unfortunately). If you start to use unsafe rust (which is necessary is some specific situations, but 99% of uses cases don't need it) you can break some assumptions the compiler makes about memory, and corrupt it, or cause segfaults, if you don't know what you are doing.
Unsafe rust is always clearly delimited from the rest of the code, so if your program segfaults, it is easy to find where the possible causes are.

@EdwardTorvalds Also, a lot of low level dependencies use unsafe. This includes the standard library. So almost all rust programs use unsafe indirectly. However the stdlib has a mathematical proof of safenesse and had been battle tested. And the community is generally against unjustified unsafe code, it is something that is avoided unless there is no better choice (and there should always be an explanation of why we think doing this is actually safe even if the compiler can't prove it).
TL;DR: yes it is.

@na
>Also, a lot of low level dependencies use unsafe. This includes the standard library.

since almost all application use standard library, all programs written in Rust is unsafe! Which is opposite to what Rust claims on the surface.

>However the stdlib has a mathematical proof of safenesse and had been battle tested.

this can be said by just about any large scale C program, but we still want to move away from C for Rust.

Things are fishy here now...

@EdwardTorvalds The idea is that you only need a little bit (like a couple of lines) of code that's marked `unsafe`, if you need it at all. (Also `unsafe` doesn't allow literally everything, it basically only allows you to dereference raw pointers and call FFI functions) That means it's *way* easier to audit the few lines where you've explicitly pointed out that you're doing something "suspicious" to show that it's safe, and then infer that the rest of the codebase must then also be safe.

@EdwardTorvalds The second idea that follows from this first idea is then that you provide safe APIs to your routines or structures that might use (a few lines of) `unsafe` code on the inside. If someone has manually verified that you're not doing anything memory unsafe in your `unsafe` lines of code, then it becomes trivial to provide a safe API to those routines that *can't* be used to cause memory unsafety to happen.

Follow

@EdwardTorvalds ...and so, even if the usages of `unsafe` in the standard library require manual auditing to verify that they are safe, programs that then use those functions from the standard library do *not* need manual auditing to prove they're safe, unless they themselves decide to include some code marked `unsafe` (which is rare).

· · Web · 0 · 0 · 1
Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!