oh boy, maybe geometry intuitions and spatial reasoning are what's really needed.

Do it twice to be sure

That was obviously a joke...

This is true for takeoffs but not for landings. You want to land with a headwind because this means that for the same airspeed you have a lower groundspeed, i.e. when you actually touch down you're going slower on the runway than if you touched down at the same airspeed but with a tailwind.

Ah

Correct. See e.g.:

https://www.businessinsider.com/3-aircraft-fly-new-york-to-l...

It's not helpful to think of it as "unsafer" but I think the way I'd explain this goes as follows:

Rust has some stricter and more complicated rules even than a language like C++. Just as in C++ you absolutely must obey these rules at all times. However, in Safe Rust the tooling will ensure that following those rules is never your problem. You don't even need to know what the rules are, just like you don't need to know why a plane works let alone how to fly it to get on a jetliner and fly across the country for $$$.

In unsafe Rust, it is your job as programmer to understand and obey these rules because the "unsafe super powers" you can use only in these blocks cannot be checked by the tooling, it can help sometimes but you can't rely on it. Writing ten lines of correct unsafe Rust is thus probably significantly harder than writing ten lines of C++. But the Rust programmer knows when they need to be at their sharpest, they need proper review by somebody paying attention, they need to slow down and think it through, versus the rest of the safe Rust where it's less scary, in C++ every line you write might be a fatal problem.

Basically, walking a tight rope is harder than everyday walking, but you know when you're on a tight rope, you've trained for it, everybody is focused on your safety - so actually maybe that's not a problem, lot of people get injured just walking about every day.

Rust allows much more aggressive optimization of the reference types than C++. If you have a &T, the compiler can assume that it will not change over the entire lifetime of the reference, and reorder things even past things that a C++ compiler would never reorder across. This can easily bite you badly if you have the mental model of C/C++ pointers and step into unsafe land. There is a separate warning for:

    unsafe {
        mem::transmute::<&T, &mut T>(t) //takes a &T, returns a &mut T
    }

in the compiler because this is something that a lot of people think might be safe (I'm running single-threaded, everything would be so much simpler if I just mutated this bit while no-one's looking), but is in fact pretty much always UB of the nasal demons type. But there are more ways to step on this problem than the most apparent way, and the compiler is not able to protect you from all of them.

To be clear, just declaring a block to be unsafe does not immediately do anything in Rust, it just allows a set of primitives that are not normally available, so it is possible to use unsafe judiciously without immediately stepping into a million landmines. You just have to be careful and ideally read the docs and the nomicon page for the operations you do, especially if they are very long.

That statement is incorrect.

It's harder to write unsafe code in Rust. That doesn't make it "unsafer". What I mean is this, if you want to write unsafe code in Rust the C++ way, your entire program has to have unsafe markers everywhere. It's just as unsafe as C++ at that point.

But if you want to write unsafe code in Rust the Rust way, you run into a requirement that didn't exist in C or C++: The abstraction around the unsafe code must be safe for you to drop the unsafe marker. This created a unique category of abstractions that no other language has, so if you are working on unsafe code in Rust you are often a pioneer doing something never done before.

The autovectorizer works quite well in llvm with all the aliasing guarantees rust gives it. Especially now fastmath hit so wide types aren't necessary anymore. I don't need unsafe or crates that use unsafe to beat the performance of c++. If you are doing something very specific with niche intrinsics llvm can't use, then maybe I'd have to use unsafe. But I don't run into that. Rust is faster for the same reasons it avoids UB. Also the Kool aid comes in multiple flavors!

I am looking at an MR a colleague threw at me right now where the code quality produced is atrocious.

Multiple redefinitions of enums - except they aren't enum but random lists of strings - that also diverge in different files.

Things consistently typed as `Any` or `dict[str, Any]` even though the functions clearly are expecting specifics, not `Any`

This is the worst MR I've had to review yet in my life. Absolute garbage.

That's true, although inconvenient for production code that needs to be delivered yesterday.

Sadly, agents don't mind generating gigatons of code instead of refactoring the abstractions.