4 ms·

> it's even harder to write correctly than it is to write sound C/C++/Zig/etc I have said very similar things in the past but I am beginning to realize that, j

> it's even harder to write correctly than it is to write sound C/C++/Zig/etc I have said very similar things in the past but I am beginning to realize that, just like with "zero-cost abstractions", this wording is highly misleading. Unsafe rust as a whole is easier to write correctly than, just to pick on the worst offender, C++. C++ has tons of footguns, like invisible effectful copy constructors and move constructors which must not invalidate their source and so on. Rust's strong type-safety features help rust avoid these kinds of issues, in all of the mentioned languages. What was really meant (or should have been meant) by the original claim is that unsafe rust introduces new rules which must be followed w/r/t pointer aliasing. But it is far from clear that the marginal new rules introduce more unsoundness than the kinds of bugs which rust prevents, in fact it seems rather unlikely. Most memory bugs seem to be the ones that are bugs in all languages, like use-after-free, etc. To my recollection, most of the unsafe-rust-specific pointer aliasing bugs which have been found in std or other popular rust libraries happened because the code was written first and then the rules got stricter! Now one can argue about the implication of the language rules changing, but the changes have somewhat tapered off in the past few years.

von_lohengramm 3y ago
I wasn't trying to argue that C/C++/Zig/etc. would be a better or safer choice than Rust. All in all, the less surface area that you have for bugs, the better, and Rust does an exceptional job at this. However, I just dislike attempts to quantify "unsafety" by thinking in terms of # of `unsafe` lines. I would rather take 1,000 trivial `unsafe ` lines than a single `unsafe` line that plays too close to the edge between what's allowed and what's not. > To my recollection, most of the unsafe-rust-specific pointer aliasing bugs which have been found in std or other popular rust libraries happened because the code was written first and then the rules got stricter! This is exactly why I have mentality. Rust is a language that grows fast and is exceedingly ambitious. Moving fast tends to break things. And while this is certainly a far less frequent occurrence than C/C++ compilers implementing new optimizations that break on UB that has historically compiled correctly, at least C/C++ compilers usually recognize that these optimizations can be dangerous to bad code and provide -O2 to keep bad codebases afloat. In general, I think the C/C++ spec was wise in being very explicit about what it does not guarantee (though its choice of what might've been questionable). If you never allow something in the first place, it's only the programmer's fault for doing it. What everyone can agree on, though, is that C/C++ compilers not providing tooling & sane defaults that help guide programmers towards good code and better practices was and is an absolute travesty. Things like UBSan have come too little, too late to restore C/C++'s reputation. UBSan and Rust's Miri are some awesome stuff, though. > What was really meant (or should have been meant) by the original claim is that unsafe rust introduces new rules which must be followed w/r/t pointer aliasing. But it is far from clear that the marginal new rules introduce more unsoundness than the kinds of bugs which rust prevents, in fact it seems rather unlikely. Most memory bugs seem to be the ones that are bugs in all languages, like use-after-free, etc. I definitely worded things poorly, but exactly. C/C++'s UB is absolute insanity, but it's well defined insanity. The workarounds are all well known, even if they're monstrous abominations. But playing language lawyer with Rust is not only a lot harder since it's underdefined, but there are plenty of things that simply don't have (known) workarounds for. "If it compiles, passes tests, runs correctly, and even passes Miri, then it can't be UB... right?" But thankfully Rust is optimistic and strives for improvement, so we have things like the Rustonomicon[0] to guide programmers towards sounder `unsafe` code. Unfortunately... > Warning: This book is incomplete. Documenting everything and rewriting outdated parts take a while. See the issue tracker to check what's missing/outdated, and if there are any mistakes or ideas that haven't been reported, feel free to open a new issue there. [0]: https://doc.rust-lang.org/nomicon/index.html https://doc.rust-lang.org/nomicon/index.html

von_lohengramm 3y ago

I wasn't trying to argue that C/C++/Zig/etc. would be a better or safer choice than Rust. All in all, the less surface area that you have for bugs, the better, and Rust does an exceptional job at this. However, I just dislike attempts to quantify "unsafety" by thinking in terms of # of `unsafe` lines. I would rather take 1,000 trivial `unsafe ` lines than a single `unsafe` line that plays too close to the edge between what's allowed and what's not. > To my recollection, most of the unsafe-rust-specific pointer aliasing bugs which have been found in std or other popular rust libraries happened because the code was written first and then the rules got stricter! This is exactly why I have mentality. Rust is a language that grows fast and is exceedingly ambitious. Moving fast tends to break things. And while this is certainly a far less frequent occurrence than C/C++ compilers implementing new optimizations that break on UB that has historically compiled correctly, at least C/C++ compilers usually recognize that these optimizations can be dangerous to bad code and provide -O2 to keep bad codebases afloat. In general, I think the C/C++ spec was wise in being very explicit about what it does not guarantee (though its choice of what might've been questionable). If you never allow something in the first place, it's only the programmer's fault for doing it. What everyone can agree on, though, is that C/C++ compilers not providing tooling & sane defaults that help guide programmers towards good code and better practices was and is an absolute travesty. Things like UBSan have come too little, too late to restore C/C++'s reputation. UBSan and Rust's Miri are some awesome stuff, though. > What was really meant (or should have been meant) by the original claim is that unsafe rust introduces new rules which must be followed w/r/t pointer aliasing. But it is far from clear that the marginal new rules introduce more unsoundness than the kinds of bugs which rust prevents, in fact it seems rather unlikely. Most memory bugs seem to be the ones that are bugs in all languages, like use-after-free, etc. I definitely worded things poorly, but exactly. C/C++'s UB is absolute insanity, but it's well defined insanity. The workarounds are all well known, even if they're monstrous abominations. But playing language lawyer with Rust is not only a lot harder since it's underdefined, but there are plenty of things that simply don't have (known) workarounds for. "If it compiles, passes tests, runs correctly, and even passes Miri, then it can't be UB... right?" But thankfully Rust is optimistic and strives for improvement, so we have things like the Rustonomicon[0] to guide programmers towards sounder `unsafe` code. Unfortunately... > Warning: This book is incomplete. Documenting everything and rewriting outdated parts take a while. See the issue tracker to check what's missing/outdated, and if there are any mistakes or ideas that haven't been reported, feel free to open a new issue there. [0]: https://doc.rust-lang.org/nomicon/index.html https://doc.rust-lang.org/nomicon/index.html