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.
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.
-- Birion as one of several fun replies to "The only consistent conclusion is that English is a weird language that needs a significant overhaul." @ Reddit - Dive into anything
Important crab-related diagnostics improvement shipping in nightly @rustlang
1.59:
error: Ferris cannot be used as an identifier
--> src/main.rs:2:9
|
2 | let š¦ = 123;
| ^^ help: try using their name instead: `ferris`
3 |
4 | for i in 0..š¦ {
|
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).
"For me, the joy of Rust comes from the fact that I can write code that represents the mental model I have of the problem" - Jon Gjengset, 2022-01-01 Q&A/AMA/Whatchamacallit.
I resonated so strong with this statement. This is the reason why I find joy in Rust and I evangelize about it.
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.