Good point, disabling asserts in production is not the best default position to have.

Straight from the uutils rewrite. This is interesting both for the class of bugs which made it (very system integration oriented, unsurprisingly) and the ones which didn't appear at all (anything to do with memory).

When possible it's nice to nest your error types, this allows better investigation when something fails.

Those have no name... but you'll encounter them regularly indeed.

A bit long for what it's saying. And yet it's a good reminder, don't focus on why... Ask the question as many times as necessary to get to the point where you can find a solution which prevents issues to reappear.

Failing DRAM chips are real. Here is the case of debugging a single bit flip.

Are you sure your understand how your reverse proxy works and the impacts it can have in production?

I vehemently agree with this piece. Fakes are unfortunately underrated. They're the most powerful test double, I wish more projects would invest in them (can be quite an investment, which the article doesn't quite show unfortunately).

There's always an interesting lesson in this kind of failures. Here clearly it is in part a story of unchecked trust, and not planning for a bigger system. It came with real consequences too.

Short explanation of why you want to make invalid state impossible to represent. This leads to nice properties in your code, the price to pay is introducing more types to encode the invariants of course.

Everyone makes mistakes, what matters is how you handle them.

Very in depth review of the mess of a Matrix home server vide coded at Cloudflare... all the way to the blog announcing it. Unsurprisingly this didn't go well and they had to cover their tracks several times. The response from the Matrix foundation is a bit underwhelming, it's one thing to be welcoming, it's another to turn a blind eye to such obvious failures. This doesn't reflect well on both Cloudflare and the Matrix Foundation I'm afraid.

Solving paper cuts pay off faster than you'd think.

Maybe we can expect improvements in how HTTP rate limiting is handled?

Error handling is still not a properly solved problem in my opinion. At least the Rust community discusses the topic quite a bit. This is good inspiration for other ecosystems as well I think.

This is indeed interesting to see how the landscape evolved around error handling. There's clearly a tension between exceptions and the result types we've seen popping up everywhere now.

A bit too unapologetic regarding Rust API choices for my taste. Still, it gives a good idea on how error handling works in Rust.

You assumed you could deserialise in a zero copy fashion? Are you really sure about that? Think twice.

A good explainer on what metastable failures are and how to try to mitigate them.

This is what you're signing up to with such ecosystems. Can't use those for backups even though people are led this way. Sure technically the data is safe on their infrastructure, but is your access to said infrastructure guaranteed? This gilded cage looks less like a gift when you loose access.