Unsurprisingly it's not all unicorns and rainbows. This piece tries to highlight the right questions to ask yourself before aiming for a rewrite.

This is a bigger trap than it sounds. It is very easy to fall into it.

More signs of C++26 being an important new standard for reliability and safety.

Interesting paper (go to the full one for all the details) which shows that with the current architecture it's really hard if not impossible to make safe systems with LLMs. This gives interesting insights in the weird form of proto-cognition those models exhibit.

A good illustration of making illegal states unrepresentable. This definitely helps with code safety.

This piece is (unsurprisingly) biased. Still there's some truth there. C++ is here to stay, like it or not. The safety issues are overblown and are getting addressed. Now where the article is lacking is that the language has other issues. Also, will profiles ever become a real thing?

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.