Pitfalls of Safe Rust
corrode.dev
Pitfalls of Safe Rust
1–10 of 145 posts
Re: Pitfalls of Safe Rust
#2Is "as" an uneccesary footgun?
Re: Pitfalls of Safe Rust
#3Title is slightly misleading but the content is good. It's the "Safe Rust" in the title that's weird to me. These apply to Rust altogether, you don't avoid them by writing unsafe Rust code. They also aren't unique to Rust.
A less baity title might be "Rust pitfalls: Runtime correctness beyond memory safety."
Re: Pitfalls of Safe Rust
#4For integer overflows and array out of bounds I'm quite optimistic about Flux
https://github.com/flux-rs/flux
I haven't actually used it but I do have experience of refinement types / liquid types (don't ask me about the nomenclature) and IMO they occupy a very nice space just before you get to "proper" formal verification and having to deal with loop invariants and all of that complexity.
Re: Pitfalls of Safe Rust
#5Is "as" an uneccesary footgun?
That was my first impression as well. So much of Rust’s language and standard library enforces correctness, that gaps start to feel way more visible.
“as” is a good example. Floats are pretty much the only reason PartialEq exists, so why can’t we have a guaranteed-not-NaN-nor-inf type in std and use that everywhere? Why not make wrapping integers a panic even in release mode? Why not have proper dependent types (e.g. to remove bound checks), and proper linear types (to enforce that object destructors always run)?
It’s easy to forget that Rust is not an ideal language, but rather a very pragmatic one, and sometimes correctness loses in favour of some other goals.
Re: Pitfalls of Safe Rust
#6Title is slightly misleading but the content is good. It's the "Safe Rust" in the title that's weird to me. These apply to Rust altogether, you don't avoid them by writing unsafe Rust code. They also aren't unique to Rust. A less baity title might be "Rust pitfalls: Runtime correctness beyond memory safety."
It is consistent with the way the Rust community uses "safe": as "passes static checks and thus protects from many runtime errors."
This regularly drives C++ programmers mad: the statement "C++ is all unsafe" is taken as some kind of hyperbole, attack or dogma, while the intent may well be to factually point out the lack of statically checked guarantees.
It is subtle but not inconsistent that strong static checks ("safe Rust") may still leave the possibility of runtime errors. So there is a legitimate, useful broader notion of "safety" where Rust's static checking is not enough. That's a bit hard to express in a title - "correctness" is not bad, but maybe a bit too strong.
Re: Pitfalls of Safe Rust
#7Some of this advice is wrongheaded. Consider array indexing: usually, an out of bounds access indicates a logic error and should fail fast to abort the problem so it doesn't go further off the rails. Encouraging people to use try-things everywhere just encourage them to paper over logic bugs and leads to less reliable software in the end. Every generation has to learn this lesson anew through pain.
Re: Pitfalls of Safe Rust
#8Golang might be better for writing robust software, if that is the goal. Robust services that don't go down.
Re: Pitfalls of Safe Rust
#9Title is slightly misleading but the content is good. It's the "Safe Rust" in the title that's weird to me. These apply to Rust altogether, you don't avoid them by writing unsafe Rust code. They also aren't unique to Rust. A less baity title might be "Rust pitfalls: Runtime correctness beyond memory safety."
It is consistent with the way the Rust community uses "safe": as "passes static checks and thus protects from many runtime errors." This regularly drives C++ programmers mad: the statement "C++ is all unsafe" is taken as some kind of hyperbole, attack or dogma, while the intent may well be to factually point out the lack of statically checked guarantees. It is subtle but not inconsistent that strong static checks ("s…
No, the Rust community almost universally understands "safe" as referring to memory safety, as per Rust's documentation, and especially the unsafe book, aka Rustonomicon [1]. In that regard, Safe Rust is safe, Unsafe Rust is unsafe, and C++ is also unsafe. I don't think anyone is saying "C++ is all unsafe."
You might be talking about "correct", and that's true, Rust generally favors correctness more than most other languages (e.g. Rust being obstinate about turning a byte array into a file path, because not all file paths are made of byte arrays, or e.g. the myriad string types to denote their semantics).
[1] https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html
Re: Pitfalls of Safe Rust
#10Title is slightly misleading but the content is good. It's the "Safe Rust" in the title that's weird to me. These apply to Rust altogether, you don't avoid them by writing unsafe Rust code. They also aren't unique to Rust. A less baity title might be "Rust pitfalls: Runtime correctness beyond memory safety."
It is consistent with the way the Rust community uses "safe": as "passes static checks and thus protects from many runtime errors." This regularly drives C++ programmers mad: the statement "C++ is all unsafe" is taken as some kind of hyperbole, attack or dogma, while the intent may well be to factually point out the lack of statically checked guarantees. It is subtle but not inconsistent that strong static checks ("s…
Safe Rust code doesn't have accidental remote code execution. C++ often does. C++ people need to stop pretending that "safety" is some nebulous and ill-defined thing. Everyone, even C++ people, shows perfectly damn well what it means. C++ people are just miffed that Rust built it while they slept.