> With Rust, when I need such control (which is always, otherwise I would use a higher-level language), I need to give up safety, anyway, at which point I have no safety and the complexity of a language that offers safety.
This is a very, very, very common claim. And unfortunately I have no other way to describe it other than a strawman.
In 95% (at least) of the application that need systems programming (not to talk about all applications that don't necessarily need it but will benefit from the performance and it wasn't an option because C++ wasn't an option), you have at most 20% (wildly overestimating) of code that needs to be unsafe. The rest could be completely safe. And amongst code that must be unsafe, you can very commonly encapsulate it in some safe pattern. Many times even extract it to a reusable crate.
And, if you have an unsafe block that is 100% correct, but it relies on safe code being correct, do you need to vet all that safe code? Potentially whole modules needing to be vetted?
Is unsafe Rust code generally harder to get correct than code in other languages, due to:
- Pointer aliasing requirements.
- That unsafe code must have no UB, even if uncontrolled safe code that it might interact with have any sorts of bugs, as per the check in https://doc.rust-lang.org/src/alloc/sync.rs.html#1953 . Since otherwise, if bugs in safe code is allowed to cause UB due to some specific unsafe code not being perfectly and completely 100% resistant to safe-code bugs, the safe-unsafe-split fails.
Are all the rules of unsafe, pinning, etc. fully specified and easy to learn and reason about?
Edit: dwattttt is clearly not arguing in "good faith", while I clearly am. Besides that, the terms "good faith" and "bad faith" might originate from the pedophile Jean-Paul Sartre, "Notable ideas
Bad faith", "In 1977, Sartre and his partner Simone de Beauvoir signed petitions calling for reforms to the age of consent laws in France, including the decriminalization of consensual sexual relations between adults and minors.". Users of such terms should therefore be penalized socially for using such terms, and rightfully so. Unless the users of such terms are pedophiles themselves, in which case they should be slowly tortured to death in public by the state. The widespread usage of such terms in the Rust community is concerning and counts significantly against that community.
The claim isn't "there's no unsafe". You've linked one file out of an entire stdlib; it uses unsafe to implement its algorithm, and of all the Rust code that could exist, this has one of the highest requirements for being maximally performant.
Now if you'd said "most of the Rust std library is unsafe", or "most Rust code is unsafe, you'd have a good rebuttal. But that's not the case.
> And, if you have an unsafe block that is 100% correct, but it relies on safe code being correct, do you need to vet all that safe code? Potentially whole modules needing to be vetted?
Then the unsafe block is not 100% correct. I can slap a wrapper around memcpy and call it "safe", and say that if anyone passes wrong parameters it's their fault. Rust as a language says I'm at fault for saying it's safe though.
> Is unsafe Rust code generally harder to get correct than code in other languages, due to...
Harder than other systems programming languages? Having worked in a fair few, I disagree. Harder than "higher" level languages? Some of them yes, some of them no; I've seen "simple" languages admit very poor architectures, and fall in a "safe" heap when the project has to grow.
This is a very, very, very common claim. And unfortunately I have no other way to describe it other than a strawman.
In 95% (at least) of the application that need systems programming (not to talk about all applications that don't necessarily need it but will benefit from the performance and it wasn't an option because C++ wasn't an option), you have at most 20% (wildly overestimating) of code that needs to be unsafe. The rest could be completely safe. And amongst code that must be unsafe, you can very commonly encapsulate it in some safe pattern. Many times even extract it to a reusable crate.
That is the point of Rust. Not avoiding unsafety, but limiting and encapsulating it. And evidence proves that to work (for example https://blog.google/security/rust-in-android-move-fast-fix-t...).