4 ms·

The rustnomicon is a very good resource. It's less of "the unsafe book" and more "the advanced book", covering lower-level details and advanced concepts that ar

The rustnomicon is a very good resource. It's less of "the unsafe book" and more "the advanced book", covering lower-level details and advanced concepts that aren't touch on by the book. One gripe I have is that it kind of pushes the idea that unsafe is bad and evil, which is not true at all: > The Dark Arts of Unsafe Rust > THE KNOWLEDGE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF UNLEASHING INDESCRIBABLE HORRORS THAT SHATTER YOUR PSYCHE AND SET YOUR MIND ADRIFT IN THE UNKNOWABLY INFINITE COSMOS. I know it's a joke, and I laughed when I first read it. Unsafe is dangerous and requires care, but unsafe == evil is definitely not true. Jon Gjengset said it well in "Demystifying Unsafe Code" [0]: > One thing I keep observing about the Rust community is how we're all like allergic to unsafe code or we think that unsafe code is is totally fine and not nothing to worry about, and I wanted to take a little bit of time to talk about what unsafe is because I think a lot of where the communities lack of alignment on this particular topic comes from a fact that unsafe is a bit of a mystery to many of us Learning about unsafe is useful, and at time necessary, it's not inherently evil, nor should it be used too freely. [0]: https://www.youtube.com/watch?v=QAz-maaH0KM https://www.youtube.com/watch?v=QAz-maaH0KM

harikb 5y ago
I do understand the point you are making, but if the goal is to discourage use, the tooling should make it easy for downstream users (other developers) to know that a certain dependency "relies on a smart programmer doing the right thing". My 2 cents - some sort of `unsafe` usage score?? I am suggesting this to prevent the likes of the burn-out that happened with actix-web and its use of unsafe (which is now fixed apparently)
- nyanpasu64 5y ago
  There exist unofficial tools for counting the number of unsafe blocks in a project: https://github.com/rust-secure-code/cargo-geiger https://github.com/rust-secure-code/cargo-geiger However a sufficiently determined evil crate can use soundness holes (like fake-static) or macros (like plutonium) to misbehave without visible unsafe.
  - jsjohnst 5y ago
    > However a sufficiently determined evil crate Nothing really can stop a truly determined bad actor completely, but I don’t think that was GP’s point, rather that it’s good to easily know the potential risk you are exposing yourself to with your dependencies in a practical sense.
- styluss 5y ago
  The issue with actix-we wasn't about people badgering the author to remove unsafe and they got tired of it/burned out and tried to find people to take over? I remember that the unsafe code wasn't really necessary with regards to the performance benefit.
tux3 5y ago
Unsafe is not evil, however as far as teaching beginners what to stay away from until they know better, I can understand why people jokingly say that it is =) It's just a tool of course, so the perspective that it's neither bad nor good is justified to an extent. But it's not that unsafe is complicated, it's that it's full of unknown unknowns. If you don't know any better, it's _really_ easy to write something not exception-safe, accidentally trust safe code a little too much to maintain invariants in your in unsafe code, or to break some other subtle assumption that prevented LLVM from merrily miscompiling what's in your head.
smoldesu 5y ago
Unsafe code is a necessity in Rust, but I actually really like how it's abstracted for a beginner. For the first few programs you write, you should be doing it the way Rust wants you to, so you can get a better understanding of Rust's ergonomics and what it's development workflow looks like. Introducing unsafe code too early could end up with people programming stuff like the Actix engine, which used unsafe code so liberally that it eventually became too difficult for the founder to maintain.
akiselev 5y ago
I'm no stranger to unsafe code but in my professional work, I avoid it almost any cost. In my experience the common denominator among average engineers is an aversion to the kind of processes that derisk unsafe code, where average == "I can reliably find at least two engineers at this skill level within the next few months with competitive but not FAANG-level salaries". This is why Rust is so successful in the first place: it's a low level language disguised as a high level language (or the way around, depending on your perspective) where you don't have to worry about fuzzing or vagrant. That `unsafe` is avoided like the plague is a great feature of the Rust ecosystem and IMO an achievement in its own right. I've actually found the reverse problem to be even more detrimental: people coming from high level languages like Python are getting tripped up because they try to go too low level to make up for tradeoffs they no longer have to make. Rust makes it painfully obvious when wrapping a shared value in a Rc+RefCell/Arc+Mutex or cloning so it seems like an antipattern to newbies. Even though the majority of them are coming from languages where everything is implicitly reference counted and performance is abysmal, they worry about incrementing an atomic integer or acquiring a lock in a program that will only ever run on x64. I can't imagine what they'd come up with using `unsafe` if the community didn't literally refer to it as the dark arts.
- iudqnolq 5y ago
  I've found I constantly want to build off of an existing c or c++ library, so I need unsafe. I'm much less experienced than the people's code I'm using, and I'm generally fine with "Rust protects against me, if the lib authors screwed up then bad things happen".
  - akiselev 5y ago
    Absolutely. I don't base my choice of libraries solely on `unsafe` but at work the number of people who will review internal unsafe code is a fraction the number of people that would review even a moderately popular open source library.
  - kibwen 5y ago
    IMO, using `unsafe` in order to do FFI is of a fundamentally different character than pure-Rust `unsafe`. To the compiler they're the same thing ("I can't verify this, be careful"), but to a reader/auditor the former is fairly reasonable ("I can see why it might be pragmatic to not have to rewrite this entire C program in Rust"), whereas the latter should raise eyebrows ("why, exactly, does this need to be `unsafe`?"). (That said, you obviously still have to be cautious when doing FFI.)
TazeTSchnitzel 5y ago
Unsafe code isn't evil, but it is scary, and I think that's what the 'nomicon is trying to get at. The reason it's scary is the risk of undefined behaviour, which is perhaps even more dangerous than it is in C, because you can completely violate the invariants that safe Rust code relies on.
the8472 5y ago
> Unsafe is dangerous and requires care, but unsafe == evil is definitely not true. The quote doesn't say it will unleash indescribable horrors. Just that it provides no warranty that it won't. That's entirely fair considering what optimizing compilers will do when you break a contract. So it doesn't say unsafe == evil. It just says evil things may or may not happen when you use unsafe.
ziml77 5y ago
I think the documentation should be very honest about how bad it actually is to use "unsafe". You don't want people reaching for it every time they think they're stuck without it, but at the same time you don't want people thinking they've written their code wrong because they had to use it. I think linked lists are a great example of something that causes Rust's ownership model to fall apart. I've seen it done with tradeoffs, but it's something that you're best off implementing with pointers and unsafe blocks (though you probably should just use a battle-tested implementation or consider if you'd be better off with a vector for cache locality).
- zozbot234 5y ago
  > I think linked lists are a great example of something that causes Rust's ownership model to fall apart. I've seen it done with tradeoffs, but it's something that you're best off implementing with pointers and unsafe blocks It's worth checking https://plv.mpi-sws.org/rustbelt/ghostcell/ https://plv.mpi-sws.org/rustbelt/ghostcell/ and https://github.com/matthieu-m/ghost-collections https://github.com/matthieu-m/ghost-collections for an alternate approach that's currently being worked on. Quite non-intuitive and it has yet to be proven 100% safe, plus it doesn't actually obviate everything you might want to do w/ potentially-aliased pointers, meaning that some desirable patterns are still off-limits - but it has the best chance of working out so far.
oconnor663 5y ago
I think one of the big existential questions for Rust early on was whether the "unsafe is evil" attitude was viable. If avoiding unsafe was very inconvenient, everyone would've kept writing unsafe code all the time, and this part of the culture wouldn't have gotten traction. Today I think it's easy to say "we all know not to use unsafe in 'normal' code", but that wasn't always a given, and it might take some more ongoing effort to keep this culture in the long term.
bestouff 5y ago
After too many years doing C/C++, I became allergic to off-by-ones, use-after-free, etc. Oh, I still enjoy an occasional carefully crafted unsafe piece of code, but it really must pay back. Otherwise I'm just lazy and prefer to be protected by the compiler. I do too many mistakes.

harikb 5y ago

I do understand the point you are making, but if the goal is to discourage use, the tooling should make it easy for downstream users (other developers) to know that a certain dependency "relies on a smart programmer doing the right thing". My 2 cents - some sort of `unsafe` usage score?? I am suggesting this to prevent the likes of the burn-out that happened with actix-web and its use of unsafe (which is now fixed apparently)

nyanpasu64 5y ago
There exist unofficial tools for counting the number of unsafe blocks in a project: https://github.com/rust-secure-code/cargo-geiger https://github.com/rust-secure-code/cargo-geiger However a sufficiently determined evil crate can use soundness holes (like fake-static) or macros (like plutonium) to misbehave without visible unsafe.
- jsjohnst 5y ago
  > However a sufficiently determined evil crate Nothing really can stop a truly determined bad actor completely, but I don’t think that was GP’s point, rather that it’s good to easily know the potential risk you are exposing yourself to with your dependencies in a practical sense.
styluss 5y ago
The issue with actix-we wasn't about people badgering the author to remove unsafe and they got tired of it/burned out and tried to find people to take over? I remember that the unsafe code wasn't really necessary with regards to the performance benefit.

tux3 5y ago

Unsafe is not evil, however as far as teaching beginners what to stay away from until they know better, I can understand why people jokingly say that it is =) It's just a tool of course, so the perspective that it's neither bad nor good is justified to an extent. But it's not that unsafe is complicated, it's that it's full of unknown unknowns. If you don't know any better, it's _really_ easy to write something not exception-safe, accidentally trust safe code a little too much to maintain invariants in your in unsafe code, or to break some other subtle assumption that prevented LLVM from merrily miscompiling what's in your head.

smoldesu 5y ago

Unsafe code is a necessity in Rust, but I actually really like how it's abstracted for a beginner. For the first few programs you write, you should be doing it the way Rust wants you to, so you can get a better understanding of Rust's ergonomics and what it's development workflow looks like. Introducing unsafe code too early could end up with people programming stuff like the Actix engine, which used unsafe code so liberally that it eventually became too difficult for the founder to maintain.

akiselev 5y ago

I'm no stranger to unsafe code but in my professional work, I avoid it almost any cost. In my experience the common denominator among average engineers is an aversion to the kind of processes that derisk unsafe code, where average == "I can reliably find at least two engineers at this skill level within the next few months with competitive but not FAANG-level salaries". This is why Rust is so successful in the first place: it's a low level language disguised as a high level language (or the way around, depending on your perspective) where you don't have to worry about fuzzing or vagrant. That `unsafe` is avoided like the plague is a great feature of the Rust ecosystem and IMO an achievement in its own right. I've actually found the reverse problem to be even more detrimental: people coming from high level languages like Python are getting tripped up because they try to go too low level to make up for tradeoffs they no longer have to make. Rust makes it painfully obvious when wrapping a shared value in a Rc+RefCell/Arc+Mutex or cloning so it seems like an antipattern to newbies. Even though the majority of them are coming from languages where everything is implicitly reference counted and performance is abysmal, they worry about incrementing an atomic integer or acquiring a lock in a program that will only ever run on x64. I can't imagine what they'd come up with using `unsafe` if the community didn't literally refer to it as the dark arts.

iudqnolq 5y ago
I've found I constantly want to build off of an existing c or c++ library, so I need unsafe. I'm much less experienced than the people's code I'm using, and I'm generally fine with "Rust protects against me, if the lib authors screwed up then bad things happen".
- akiselev 5y ago
  Absolutely. I don't base my choice of libraries solely on `unsafe` but at work the number of people who will review internal unsafe code is a fraction the number of people that would review even a moderately popular open source library.
- kibwen 5y ago
  IMO, using `unsafe` in order to do FFI is of a fundamentally different character than pure-Rust `unsafe`. To the compiler they're the same thing ("I can't verify this, be careful"), but to a reader/auditor the former is fairly reasonable ("I can see why it might be pragmatic to not have to rewrite this entire C program in Rust"), whereas the latter should raise eyebrows ("why, exactly, does this need to be `unsafe`?"). (That said, you obviously still have to be cautious when doing FFI.)

TazeTSchnitzel 5y ago

Unsafe code isn't evil, but it is scary, and I think that's what the 'nomicon is trying to get at. The reason it's scary is the risk of undefined behaviour, which is perhaps even more dangerous than it is in C, because you can completely violate the invariants that safe Rust code relies on.

the8472 5y ago

> Unsafe is dangerous and requires care, but unsafe == evil is definitely not true. The quote doesn't say it will unleash indescribable horrors. Just that it provides no warranty that it won't. That's entirely fair considering what optimizing compilers will do when you break a contract. So it doesn't say unsafe == evil. It just says evil things may or may not happen when you use unsafe.

ziml77 5y ago

I think the documentation should be very honest about how bad it actually is to use "unsafe". You don't want people reaching for it every time they think they're stuck without it, but at the same time you don't want people thinking they've written their code wrong because they had to use it. I think linked lists are a great example of something that causes Rust's ownership model to fall apart. I've seen it done with tradeoffs, but it's something that you're best off implementing with pointers and unsafe blocks (though you probably should just use a battle-tested implementation or consider if you'd be better off with a vector for cache locality).

zozbot234 5y ago
> I think linked lists are a great example of something that causes Rust's ownership model to fall apart. I've seen it done with tradeoffs, but it's something that you're best off implementing with pointers and unsafe blocks It's worth checking https://plv.mpi-sws.org/rustbelt/ghostcell/ https://plv.mpi-sws.org/rustbelt/ghostcell/ and https://github.com/matthieu-m/ghost-collections https://github.com/matthieu-m/ghost-collections for an alternate approach that's currently being worked on. Quite non-intuitive and it has yet to be proven 100% safe, plus it doesn't actually obviate everything you might want to do w/ potentially-aliased pointers, meaning that some desirable patterns are still off-limits - but it has the best chance of working out so far.

oconnor663 5y ago

I think one of the big existential questions for Rust early on was whether the "unsafe is evil" attitude was viable. If avoiding unsafe was very inconvenient, everyone would've kept writing unsafe code all the time, and this part of the culture wouldn't have gotten traction. Today I think it's easy to say "we all know not to use unsafe in 'normal' code", but that wasn't always a given, and it might take some more ongoing effort to keep this culture in the long term.

bestouff 5y ago

After too many years doing C/C++, I became allergic to off-by-ones, use-after-free, etc. Oh, I still enjoy an occasional carefully crafted unsafe piece of code, but it really must pay back. Otherwise I'm just lazy and prefer to be protected by the compiler. I do too many mistakes.