There are lessons and inspirations to find in how the Vulkan API is managed. The extension system can be unwieldy, but with the right approach it can help consolidate as well.
Interesting essay looking at how systems evolve their schemas over time. We're generally ill-equipped to deal with it and this presents options and ideas to that effect. Of course, the more precise you want to be the more complexity you'll have to deal with.
The complexity and cost in organisations is indeed mostly about coordination. This is a difficult problem and largely unsolved in fact.
Good historical perspective about the attempts to get rid of developers. This never unfold as envisioned. This is mostly about the intellectual work to build artifacts handling the world complexity, and this doesn't go away.
This is a very nice satire website about the problems in our industry. Want to work in a resume driven context? Here is how!
OK maybe a longer piece than it should be. Still the idea is interesting. Clearly you want to mind the O(n) coupling in this context.
This looks like an interesting way to frame problems. It can give an idea of how likely they can be tackled with LLMs. It also shows that the architecture and the complexity greatly matter.
Interesting tool and I like the underlying approach. I wish we'd have good equivalent tools for other ecosystems.
A nice little primer on what systems thinking is about.
Finding the right level of abstraction for the tests is important indeed. It helps keep them useful longer. Scope and complexity are linked and can help find the right balance of tests.
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.