First Rust code shows up in the Windows 11 kernel
thurrott.com
thurrott.com
# of safe lines is key
In Rust even when using lots of unsafe, it's usually possible to compartmentalize/modularize it and build safer, harder-to-misuse interfaces on top of the unsafe code. With this you can test and fuzz one tricky thing at a time, instead of having to prove safety of the combined product.
Plus Rust has other features that help with software reliability, like sum types with pattern matching, which are used to make non-nullable types and mandatory error handling, top-notch compiler warnings and lints, and types to describe thread safety.
Check out Redox OS — it has lots of unsafe blocks, but mostly safe interfaces between them. Same in Rust for Linux — they're building higher-level building blocks for all the unsafe primitives that Linux requires.
Most systems languages that are actually being used out there in the wild have weak type systems that must be thrown away at a moment's notice. C++ is a notable exception but it is a very complex language where errors can be extraordinarily subtle compared to other systems languages: This is the main reason people still use C even though it is essentially not type-safe at all. Unsafe rust avoids both of these pitfalls: unsafe rust is just as type-safe as safe rust, and it has RAII without C++'s strategic arsenal of footguns.
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.
> 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.