When a programmer writes get_unchecked , we can imagine them wanting to promise the compiler that they uphold its preconditions. But since the compiler is normally not so trusting of unproven assertions, the programmer swears an oath that their argument is in bounds.
The compiler, seeing such a solemn commitment, treats the programmer's word as true and optimizes accordingly. The compiler is so thoroughly convinced that it never even entertains the possibility of doubting the programmer's oath.
But if the programmer has sworn falsely, then they might well suffer divine retribution in the form of nasal demons — or worse, subtly baffling program behaviour.
unsafe is an oath by u/scook0 (I solemnly swear as a keyword when?)
I think, this is a very interesting insight which probably worth sharing with the community.
A tempting alternative to the onboarding problem is to spin off a small sub-team of budding Rust experts to work on mission critical components that require Rust levels of performance or type safety. This was a mistake we made on the Magic Pocket project where a handful of engineers rewrote the storage engine in Rust while the rest of the team continued building the rest of the system in Go. This split was necessary when the Rust components were a small skunkworks project but it persisted for years afterwards.
The Rust components were a victim of their own success — they worked well, didn't require much maintenance, and by the time the original authors left the team to work on Nucleus there weren't many engineers left who were experts in these very-large systems. This slowed innovation on the Rust components for a period of time and left the remaining team with mixed feelings about the use of Rust to begin with.
The design of the safe/unsafe split means that there is an asymmetric trust relationship between Safe and Unsafe Rust. Safe Rust inherently has to trust that any Unsafe Rust it touches has been written correctly. On the other hand, Unsafe Rust cannot trust Safe Rust without care.
As an example, Rust has the PartialOrd and Ord traits to differentiate between types which can "just" be compared, and those that provide a "total" ordering (which basically means that comparison behaves reasonably).
BTreeMap doesn't really make sense for partially-ordered types, and so it requires that its keys implement Ord . However, BTreeMap has Unsafe Rust code inside of its implementation. Because it would be unacceptable for a sloppy Ord implementation (which is Safe to write) to cause Undefined Behavior, the Unsafe code in BTreeMap must be written to be robust against Ord implementations which aren't actually total — even though that's the whole point of requiring Ord .
There's a constant focus on backward compatibility, but the (equally constant) feature creep will inevitably break it. English hasn't moved from version 3.x for centuries, and we still have multiple redefined keywords, many modern compilers have dropped support for outdated constructs which -- though legal -- haven't been in use for ages, and in fact the very language has several different implementations with varying levels of mutual compatibility.
Please do not publish this one, (EDIT2: I don't think it's worth publishing) I just fond the slip of the tongue very funny!
EDIT: this post has been flagged as off-topic. I would have like to know why. This is a citation, about Rust, from a very interesting conference, and I selected it because it was funny. And while I think its not worth publishing it in TWIR because it doesn’t bring any new insight about Rust, I think it has its place in this thread for the pleasure of people that propose and vote for TWIR citations.
This thread is for submitting Quotes of the Week for This Week in Rust. If you don’t want your quote to be published, then it probably doesn’t belong here (though TWiR quotes that are just funny have been published before).
(The elision there is to avoid making any commentary on the actual issue in that topic part of the quote; in general, I think we should avoid highlighting quotes that directly comment on one side of an active topic, so I left that part out.)
I’m saddened to think that because this industry has an obsession with making programming accessible to the lowest common denominator, expressive and innovative languages like Rust will fall by the wayside, and we’ll all be writing code in languages like Go and Python in the future because they’re “easy” and even high schoolers can learn them in a couple days.
The context of that thread is already interesting on its own, but I even think that taking that quote seriously / in a first degree fashion is actually meaningful: for some codebases written from scratch and which developed features out of an initially thin core, the newly obtained perspective on the problem ought to make rewriting that codebase "from scratch" yield cleaner, leaner, and potentially faster code (and back to that RiiR thread, hence why sometimes the Ri part may be just as important if not more important than the iR part).
I see a lot of “we rewrote X in Rust and it got faster” posts. I think that if you rewrite anything from scratch with performance in mind, you’ll see a significant performance improvement. I’m suspicious of how much Rust itself is needed versus the developers having some performance discipline.