Didn't know this kind of architectural pattern had a name. Interesting. I wouldn't recommend it in any context though, but one more metaphor to reason with.

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.

There's clearly a tension between security and ease of pulling dependencies. In a way, it's "too easy" with cargo and you very quickly end up having to trust a staggering amount of third party code.

Illustrated with the Clojure ecosystem, bit there's nothing inherently specific to the language here. If you want to ensure stability to your users, you need to manage your APIs properly and this article put forward a couple of interesting ideas.

Clearly there is too much telemetry in most browsers by default and it's worsening. There are a couple of exceptions though.

Or why I really hate the whole certification business. Especially for process and practice's related topics, this pushes the multiplication of brands and churches to sustain them. The right approach is almost always a blend of different influences and flavours.

It's written and illustrated in a C++ context, but the advice is widely applicable. You should know well the libraries you use on your projects.

Looks like the protocols landscape for writing LLM based agents will turn into a mess.

Or why it's important to deeply understand what you do and what you use. Cranking features and throwing code to the wall until it sticks will never lead to good engineering. Even if it's abstractions all the way, it's for convenience but don't treat them as black boxes.
Interestingly this article draws a parallel with organizations too. Isn't having very siloed teams the same as treating abstractions as black boxes?
Quite some food for thought here.

Nice docker recipe indeed for small and secure containers when you just want to ship a statically linked binary.

A nice example which shows the value proposition of Rust is not simply memory safety. Having a stricter type system and properly designed based types help a lot to catch mistakes early.

Good advice on how to learn Rust. I recommend quite some of it.

The ranges are improving in the STL. This is definitely welcome.

There are many opportunities to redactor. This one is aligned with Kent Beck's quote: "first make the change easy, then make the easy change".

This remains the best explanation of why we should have more use of auto in C++ code.

Definitely a handy catalog for designing distributed systems.

You have to know which battles to pick. If you don't... This article shows well what will happen. And it'll indeed turn into a curse.

Looks like a nice tool to navigate mistakes with Rust complex type system.

Even with conservative estimates some uses are very much energy hungry... Especially when they support a surveillance apparatus. Many reasons to not get there.

Little known docker feature but definitely useful for remote execution.