Interesting! I wonder how much of this improvement is actually due to Rust. I suspect implementing the same approach in C would produce similar results. The speedup seems hardware-level optimizations than the language itself.
The rewrite itself is amazing, but I don't think folks realise the actual conditions that made it possible. It's not as simple as a company spending ~$160K on tokens.
This was done by someone who has essentially already rewritten Node once. Bun itself is a reimplementation of Node, so the author was walking in knowing exactly what the correct behavior is. And an exhaustive amount of test suite to verifiy the changes?. On top of that, there is a reference from Node and V8 to validate more throughly. So the $160K is simply the price of translating knowledge that already lived in one engineer's head in a newer syntax.
I have always found similarities between programming and filmmaking.
Programmer being the director and the LLM being the entire apparatus upon which the film/software is built. This became evident to me while doing spec-driven development for a few of my projects where I specify the constraints upon which the software should be build, but have limited control over the performance similar to how a director has limited control over an actor's performance.
Nice writeup. If I am reading it right, the core bug was that two independent paths each generated the per-invocation namespace, and the fix was to generate it once and propagate it to the workers. That reads more like an implementation slip than a design failure. The multi-level naming scheme is sound, it just has to be computed in exactly one place.
The part I would actually love more detail on is the agent side. How are you orchestrating agents to fan out the test runs?
I agree with some of reasonings in the article especially around agents write behaviors. However, a large portion of this is a consequence of poorly-defined agent roles, and moving away from building deterministic systems.
> An agent working on a customer analytics task might issue a join across five tables that has never been issued before, hold the connection while it thinks about the result, then issue a completely different follow-up.
Aren't agents simply automated human persona's? Like, why would an Agent make a join across five tables given that its reasoning is grounded on human-aligned decisions. For eg.
If the agent knows the schema, and is aware of the indexes defined. Then, shouldn't it only work its way through those 'known paths'. Why would you allow the agents to deviate known paths?
> Then came the pricing. The last quote I got for one of the tools on the market was $6,000/year for a team of 16 people in a use-it-or-loose-it way. For a tool we use maybe 2–3 times per sprint.
I could be wrong, but the idea of ending backend and front end reactivity (or sync) is not a good idea. As far as I understand FE reactivity occurs when there is an action but the backend reactivity doesn’t require an action there could be backend jobs that sync state between two components.
I enjoy building frameworks and libraries for fun, so kudos to you for that. At first glance, BlackSheep seems to combine the aspects of Flask, Django, and FastAPI. However, I’m a bit skeptical about its ability to coexist alongside them. The one feature I believe could drive the success of the next Python framework is the ability to operate in nogil mode.