Very Rust focused, still it's an interesting debate. It gives a good overview of the different types of lock behaviors in case of failures. It's very much advocating for the poisoning approach which is indeed an interesting one (coming with its own tradeoffs of course).

Depending on the ecosystem it's more or less easy indeed. Let's remember that error handling is one of the hard problems to solve.

The findings in this paper are chilling... especially considering what fragile people are doing with those chat bots.

Wondering what happened at Cloudflare? Here is their postmortem, this is an interesting read.
Now for Rust developers... this is a good illustration of why you should stay clear from unwrap() in production code.

If you're dealing with multithreading you should not turn to mutexes by default indeed. Consider higher level primitives and patterns first.

The type inference in C++ can indeed lead to this kind of traps. Need to be careful as usual.

Interesting work from Apple and Google to have better hardening in libc++. It's nice to see it ripples through the upcoming C++26 standard as well.

Your digital life is secure? Good... now is it really safe? Can you recover in case of a catastrophic event?

Indeed, stress can't be completely eliminated... but at least build an environment where risky situations are reduced as much as possible. So that when stress or anxiety shows up you can take notice and react. Otherwise you'll be creating vicious circles.

For as much as we collectively like to complain about C++ it's important to also give credit where its due. Now I don't necessarily agree with everything in this one even though it provides a few good arguments.

C++26 really looks like a step in the right direction in term of safety. Undefined behaviours are too often neglected in that conversation.

This is indeed an area which could be better handled in SQLite. It needs to be carefully checked when introduced in a project.

Clearly the error handling landscape still evolves in Rust and that's a good thing. The current solutions are too fragmented at the moment.

Probably biased, but this raises questions about xz.

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.