Error handling is not easy. Having simple rules to apply for complex systems is a good thing. Of course the difficulty is to apply them consistently.

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.

A bit of an advertisement toward the end. That said, the evaluated constraints are completely valid. You don't want to fit your whole code base into the "cloud function" model, only a few workloads will make sense there.

Indeed, in most case you don't need the extra complexity. Also interesting is showing that even if the application has to scale rapidly you still got quite some time to plan the transition to something else. It makes Postgres a sane default choice.

This is a very valid question. The most likely answer is somewhat cruel though.

Indeed it feels like the Rust community has a cultural problem around abstractions. In a way it feels similar to the one Java developed years ago. This can bring lots of complexity and obfuscation you don't want in your project.

Serverless based architectures leading to bad cases of complexity and latency when used for more than trivial workloads... who knew!? ;-)

A reminder that if there's too much complexity in your configuration the syntax used to represent it probably won't save you from issues.

Indeed, most complaints against "Don't Repeat Yourself" (DRY) are really arguments against a strawman. Of course you can go wrong, it's like everything else it's about balance... reducing the DRY guideline to a caricature to get rid of it won't help.

Maybe a bit extreme as an example, but highlights quite well why you want to limit logic in tests as much as possible.

An old series of posts which highlights quite well why GitFlow can be a problem and that you likely want something simpler. Since I still find GitFlow often recommended as a knee-jerk reaction, this is a good article to have in hand.

Yes an external cache is definitely faster. That said does your application need the extra complexity? Is the caching in database really the bottleneck? If not, the question of the external cache is still open.

Of course I agree with this. We should fight undue complexity at every step. This beast tends to creep up very quickly and we're all guilty of it at times. This is indeed particularly obvious in otherwise rich languages like C++ or Rust. Those tend to push people to try to be clever and show off, often for "performance reasons". This is rarely a good idea, think twice.

I would have titled the "defer refactoring" section differently though. Probably "defer abstracting" would have fit the bill better.

And a bunch of tool to use with it... But you can indeed do a lot with just SSH. This post gives a few good ideas.

Sometimes, it's indeed better to not pull an extra dependency.

Good reminder of this important but imperfect guide to software design. There is some ambiguity on what "simplest" actually means. Still it helps keeping in mind that simple is rarely easy to find.

Ever wondered about how Windows 3 was architectured? This is an interesting read. It was really complex though, you can really tell it's in the middle of several transitions.

Indeed, if you can guarantee your materialized views to always be up to date, you might be able to get rid of some caching... and thus some complexity can be avoided.

Indeed, let's not fall for the marketing. It's better to write less code if it's enough to solve actual problems.

A good list of things to consider when designing systems. And indeed in case of success the result looks probably boring.