A bit of a long read, but does a good job explaining the use of assertions and how to introduce them in your organization.
Interesting point, fairly logical but didn't sit to think it through before. Indeed, using arenas to get back features of manual memory management won't lead to the same security issues than outside of a memory safe language.
There are indeed other options beyond the model with "one enum with all the errors".
Nice move. It doesn't have to be about rewriting everything in Rust. Still there are some areas where we can benefit from the language and sandboxing.
Interesting paper about metastable failures and novel approaches to try to analyse them. It's early days but we would need to get toward better prevention.
Interesting post about the options for error handling in Rust. It highlights the tradeoffs to keep in mind when creating structured errors.
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...