Interesting ways to look at processes and their outcomes. Depending on the mental model you won't ask the same questions when investigating incidents.

I find the title misleading. Still, this is a good exploration of how to treat unwrap() and expect() in Rust code.

Security asks for more than a memory safe language. It helps some things for sure, but there are tools for other languages as well, you better start using them.

This is a nice little experiment. Not statistically relevant (there are other papers for that), but shows in the details how introducing Rust can impact the way people work. This is interesting because it means the safety gains are not only strictly coming from the (now infamous) borrow checker. We can't rely on everyone applying all the techniques necessary but for sure they're cheaper to put in place than with C.

Sure, you get good memory safety with Rust. It's important and welcome, but it's just the beginning of the story.

Nice feature, but more interesting in its explanation is the topic of static initializers in Rust. They're clearly not a settled area in the language, that's in part because of how low level static analyzers are.

Rust itself might bring interesting properties in term of safety. As soon as it needs to interact with other languages though the chances of undefined behavior increase drastically. This definitely pushes towards using more dynamic analysis tools to catch those.

In case it wasn't clear yet that not relying on Lidar was a stupid move for self-driving cars.

This could be a big improvement for C. We'll see how far this goes.

Interesting reasons to let go of Rust, some spaces indeed can have a safety vs performance tradeoff which would justify using good old C.

Another illustration that with race conditions all hell can break loose. It's not only about data corruption or deadlocks. This case is explored in depth which is nice, also compared across several languages.

They help with some issues... but they can't solve all the memory safety issues of the language I'm afraid.

Always be careful with regular expressions indeed. It can badly backfire.

A harsh reminder that getenv is not thread safe...

JSON is full of pitfalls. Here is a good summary. Still it is very widespread.

Interesting piece, it highlights well the struggle for the C++ community to come up with a cohesive approach to improve safety. It doesn't look like the solution is going to come from the standardization committee (unfortunately).

Good explanation of what Rust's unsafe really does.

It's clear that a split is forming in the C++ community on how to evolve the language. Could it lead to a full fledged divorce?

If you still needed to be convinced you need to use std::array and std::span, here is the proof.

Excellent proof of why you don't want to "rewrite it all in Rust". It's important to respect the old code and focus on applying safety practices on the new code. This is also why the upcoming changes to C++ are worth it, it might improve the interoperability factor almost for free.