Alternative licenses like the Forklift Certified License are a good and necessary counter-reaction to open source becoming a corporate hollowed out shambles.
When people say that Kubernetes is complicated, this is the stuff they mean. As far as I can tell, there’s no way to play this complexity game reliably, so the only reasonable way through would be not to play.
If your reliability depends on heroic efforts or arcane knowledge from individuals, then you have no reliability. This week’s AWS outage shows that clearly. Whatever conclusions you draw from that is up to you.
We really should have Starlark as a configuration language everywhere because it’s very expressive and easy to read/understand. Instead we’re stuck with ever increasing piles of YAML and obscure configuration formats that nobody wants to deal with.
It’s always been my feeling that TLS has unacceptable collateral damage in how it breaks the web for normal people. That’s considered a bit of a crank opinion, but I’m definitely not the only person who feels that way.
The Bitter Lesson is an interesting concept. Stuffing the prompt runs into diminishing returns pretty quickly but on the other hand, getting your AI to play well with tools is challenging.
Every programming language has to strike a balance when it comes to abstraction and none of them get it right. Rust is written in a way that is often too abstract for the things that you want to do with it.
We should have more histories of software. There are lots of things that have been tried out and learned which if they aren’t captured will disappear entirely.
The guide to sqlite query planning and tuning is cool, but what’s even better is that this kind of scale and optimisations are possible at all with sqlite.
The situation described here where AI writes 90% of the code is almost entirely the same as how any software engineer works already. The only thing that’s changing is that instead of code you’re writing instructions to the LLM.
Every time I have to cross-compile something (usually in Rust to run on the cloud somewhere) it’s always rather confusing to figure out the correct target triples. Weird that something that’s this fundamental is documented this poorly.
The write-up how Bun can be so fast is a good exploration in all the things that computers are good at now. Machines and our networks have gotten much faster and much more parallel which influences what an optimal approach to building software is now.
A good description of how if software engineering was setup for speed of iteration we would have entirely different environments than we have now. Nobody is really opposed to speed, but nobody really wants it either so we end up with bloated development and bloated results that are the worst of all compromises.
This may sound harsh, but it’s a lot fairer than they deserve: “But since the product is no longer jumping exponentially in capabilities, they will need to fall back on proper product development if they want to be competitive. They need to accept that they are software—plain old software—and that means people need to be able to use it.”
A very cool and simple introduction into Lean and what makes it interesting. I’m not sure exactly what draws people in this direction but it’s cool to see the progress that’s being made here.
Perplexity lost its momentum almost a year ago and everything they’ve been doing since has been stuff like this. It takes some effort to stand out as a bad actor in a field like this, but here they are.
I had a very similar mediocre experience using LLMs with Python/Rust/Typescript where I didn’t really see the point. Only when I started using Go for a recent hackathon project did I get the fully hands off experience where I didn’t have to write any code.
Solvers are very annoying to setup and plug your problem into if you’re using them regularly. That’s why hooking them into LLMs to do the annoying manipulation work is an amazing idea.
I’ve found it very useful to use jj to continuously and automatically snapshot the changes that Claude makes. This way if it does anything that I didn’t want, it’s incredibly easy to undo it and still keep a clean history.
At scale you will be slapped in the face by this tail or that all the time. It’s a clear and simple argument to rehabilitate the mean as the measurement we should be looking at.
For the many people who may not be intimately familiar with the workings of Turing machines, this visual and interactive guide should get them up to speed really nicely.
A very informative write-up of how you would squeeze out the last bits of performance out of a Rust port. Not sure if I’d ever apply this but I’m happy enough that I can mostly follow along.
To hearken back to the previous comparison of Java versus compiled languages, AWS has a case here where a naive rewrite of their JVM database in Rust created massive performance wins.
It’s relevant to my interests to read how others have massively scaled the systems we use. Discord has a solid write-up here of how to deal with Elastic Search.