There's a common trope among people unfamiliar with rust where they assume that if you use unsafe at all, then it's just as unsafe as C and rust provided no benefit. Comparing C's approach to safety vs Rust's is like comparing an open world assumption to a closed world assumption in formal logic systems . In C, you publish your api if it's possible to use correctly (open world). In Rust, you publish a safe api if it's im possible to use in correctly (closed world). Rust's key innovation here is that it enables you to build a 'bridge' from open world (unsafe) to a closed world (safe), a seemingly impossible feat that feels like somehow pairwise reducing an uncountable infinity with a countable infinity. Rust's decision to design an analogous closed-world assumption for safe code is extremely powerful, but it seems very hard for old school C programmers to wrap their head around it.
Rust is the language where you get the hangover first.
Unattributed, via RustConf 2021 - Project Update: Lang Team by Niko Matsakis
The biggest failure in Rust‘s communication strategy has been the inability to explain to non-experts that unsafe abstractions are the point, not a sign of failure
By withoutboats at tweet
By micha_38 in the Berline.rs Matrix Chat:
...[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