...[T]he fastest and most reliable way to make slow rust code fast is to post it on r/rust saying that it's slower than corresponding Go code, and then watch other people optimizing it.
While talking about API design
I think in general "force the user to think about the extra cases, and be explicit about ignoring them" is definitely idiomatic rust.
I just said something which, in hindsight, might appeal as a quote of the week:
Rust is very much about patching or working around wetware bugs.
(Said in the context of arguing that the orphan rule is about preventing programmer burn-out and that machine analysis has shown that we may be better at it than memory safety, but we're not very good at stable ABIs either.)
I always tell myself that code quickly written just to compile looks like Order 66 executed on Christmas day.
Clones and unwrapping as far as the eye can see.
What you'll find is that when Rust developers are freaking out about "bad performance", the "bad" performance is still usually hundreds of times better than dynamic languages
it's just bad compared to perfect optimized ideal Rust code
Pauan on the future-signals Discord server
Confusingis not general enough; expected
It seems like things always get confusing fast when higher-order lifetimes show up…
from the recent forum thread Argument requires that ... is borrowed for
'static (it is a great thread btw.)
And even if you could fix all of rustc's soundness holes, or otherwise prevent user code from exploiting them, a soundness bug in any third-party library can also make it possible for malicious crates to trigger arbitrary behavior from safe code.
This is why we need to emphasize that while Rust's static analyses are very good at limiting accidental vulnerabilties in non-malicious code, they are not a sandbox system that can place meaningful limits on malicious code.
Wait until you go back to Python after some time in Rust. Returning whatever you feel like from a function, having potentially uninitialized variables of whatever type, and all the other things that make Python fun feel like drunk driving a 747 when you come back.
DonLemonAIDS replying to “had my first rust moment today”
do not use
RUSTC_BOOTSTRAPunless you're rustc bootstrapping
Probably a good rule of thumb is any SIMD code done at id software will be too clever to abstract away with SIMD libraries that aim to make it easier.
Not sure if this can be trimmed down to be suitable, but it's just so elegant:
If a normal add is a waffle iron, SIMD add is a double or quadruple waffle iron. You can make 2 or 4 or more waffles at the same time.
In case of waffles it would be called SIMW: Single Iron, Multiple Waffles.
It's not multithreading - because you open and close the waffle iron for all the waffles at the same time.
I love this explanation! Multi-threading would be having many chefs working independently.
SIMD allows a single chef to make many waffles at the same time.
The drawback is that the 4-waffle iron can only make 4 waffles at the same time. It can't make, for example, two pieces of toast and two waffles. There's also a toaster that makes 4 pieces of toasted bread at the same time, but that machine can't make waffles.
So if you really want one piece of toast and one waffle made as quickly as possible, you're better off hiring two chefs.
And a common issue with kitchens trying to upgrade to SIMW, that they don't have their ingredients arranged properly. For example, you don't want to use a regula-size batter ladle to fill the
vectorbatch waffle maker. You want a big ladle that can fill the whole machine without a lot of wasted movement. And if some of your waffles are blueberry and others are banana, that's fine, but you don't want the chef to have to walk around grabbing each ingredient while the machine sits idle. Everything works better if you have the ingredients lined up and ready to go right next to the machine. All of this is doable, but it's important to plan these things carefully when upgrading a kitchen to SIMW, to get the most value out of the machine.
Wonderful! I feel this analogy works 100%.
Even without SIMW, some superscalar chefs may actually cook multiple waffles simultaneously. Some may even process customers out-of-order, making many quick waffles while waiting for a pizza to bake.
It is even possible to speculate on incoming orders, and start making a blueberry waffle before the topping is even decided! If the topping-predictor makes a bad prediction, the waffle can just be thrown away. In the long run, it is correct often enough to increase throughput!
EDIT: And even more great additions are still being made to the thread, like a waffle-based explanation of speculative execution vulnerabilities.
std::collections::GjengSet: A heterogeneous collection of excellent Rust explanations.
Also GRATZ JONHOO WOO
It's not specifically related to Rust, but it's good advice all the same.
I just wish I has spelled "whose" correctly.
I used to think that most amazing thing about Rust was that it was able to take solid research and apply it to a system that has quickly gained industry adoption.
I no longer think that. Rust is a byproduct of the governance model, it is the governance model that enabled a group of people to create Rust. And the governance model is the most valuable technology created from the Rust experiment.
u/fullouterjoin on reddit: https://reddit.com/r/rust/comments/qw1chb/_/hl3b65o/?context=10
On the topic of reframing UB, I was reminded of an article about the mechanics of oaths and vows in historical cultures.
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
Ordtraits to differentiate between types which can "just" be compared, and those that provide a "total" ordering (which basically means that comparison behaves reasonably).
BTreeMapdoesn't really make sense for partially-ordered types, and so it requires that its keys implement
BTreeMaphas Unsafe Rust code inside of its implementation. Because it would be unacceptable for a sloppy
Ordimplementation (which is Safe to write) to cause Undefined Behavior, the Unsafe code in BTreeMap must be written to be robust against
Ordimplementations which aren't actually total — even though that's the whole point of requiring
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." @ https://www.reddit.com/r/rust/comments/r3m8y5/an_mut/hmcdvh2/