@roadriverrail for clarity's sake, it should be mentioned that the memory safety issues they found all comes from "unsafe" code, which, as its name implies, doesn't ensure safety. This comes from developer's choice to write unsafe code, and not Rust in itself.

@morgan You're technically right, yes, but not practically right.

@morgan @roadriverrail I guess one point is the fact that these libraries often *have* to resort to unsafe code for performance or functionality (i.e. Rust is not powerful enough to gain optimal performance AND safety in all cases). Though, I think this is a bit too much to ask. In the end, there's only so much that can be automatically checked (e.g. Rice's theorem). If you want to fully ensure safety AND optimal performance, I think eventually you need to resort to manual formal verification.

@morgan @roadriverrail Btw, very interesting paper, thanks for the link! Of course, Rust is still a significant improvement over C/C++ wrt. memory safety as the article and paper also explain (i.e. you can focus on the unsafe blocks and you can get quite far with safe Rust).

@TimSueberkrueb @morgan Yes, to be clear, I am still quite fond of Rust. This is not about Rust as a language. This is about certain incorrect cultural constructions surrounding it.

@TimSueberkrueb @morgan If you need to eventually perform IO, then, yes, there will eventually be something volatile which risks safety. That said, the question of when one "has to" go to unsafe blocks is also a bit of a judgment call; there are plenty of unsafe blocks out there that exist for dev convenience, and what happens in an unsafe block can taint the "safe" code. This is not about Rust as a language but about folklore surrounding Rust.

@morgan When you have a build system that's built around fetching modules from Github and building them in place transparently, it's trivial for your project to create an indirect dependency back to a block of unsafe code that's tainted all your safe code. That is, a "developer's choice" can impact you without your knowing unless you audit every last dependency.

@roadriverrail thanks for taking the time of answering. For some reason, i though using unsafe depedencies meant you had to declare it that way in your project, and thus be perfectly aware of the stability of your code.

I've browsed some common depedencies and I am aghast to see how many resorts to unsafe blocks. Serde, log, anyhow, lazy_static, even regex ? These are basic crates for any medium projects. Will definitely look into this more, thanks for sharing.

@morgan Okay, but even if you flag a project as one that uses unsafe blocks, so people can avoid it, what happens when the general standard go-to crate for something important needs its unsafe blocks?

Moreover, this is not about whether or not Rust is a good language. It's about how "rewrite it in Rust" is a slogan that hides complexities. Yes, a rewrite of a critical module might mean it's in a more safe language, but rewrites are going to contain bugs, especially in unsafe blocks.

Sign in to participate in the conversation
Signs & Codes
