Rewriting Bun in Rust

Sounds like a good time to tell Claude to create a system wide memory of how to implement lifetimes and borrowing and what to NEVER do.

Claude will then make the memory file. Usually memories help a lot. I see it think about it when it reasons through code.

experiencing the gpt3->4o->sonnet4->opus4.6->fable trajectory I am fairly confident what we call programmer today will not exist, in the same time regular people will finally be able to tell computers what to do and this will unlock the next stage of complexity in manufacturing/material science/medicine and so on.

of course I am likely wrong, people say: its never as good or as bad as you think.

That's what underlies most of the vitriolic reaction to the events, it was done really in a really rash way.

All they had to do was a)not gaslight people about your intentions when they found the branch b)publicly post the intent to do this, and then c)publish a doc like this one right before merging, ideally leaving the branch open for like a week in case anyone in the "community" finds things to fix.

Then those UB/Miri issues others found would have been "yay collaboration" boosts instead of negative issues that prove that the approach was risky/unthoughtful.

If you're going to cross a rubicon, maybe tell people a)that you actually want to do it, b)why you want to do it and c)what it looks like after you've done the rewrite.

I'm very glad to see a holidtic approach to the memory errors and segfaults. I was tinkering on a static webpage just this this weekend, using Bun as the transpiler+bundler since it's so turnkey, and I ran into a few segfaults. E.g. when Bun saw I used an empty data uri for the favicon (avoids the browser trying to ask for one) it'd just crash. It reminded me of my own tinkering with Zig in its current pre-release state where it's usually a good mix of my poor memory management and working around bugs in Zig itself.

This post is also the best ad for AI I've seen yet. Not just comments saying they have 10xed themselves, a small personal project or thing which can (and likely will) be abandoned next month, or a one off dump of unusable code for the world's buggiest C compiler (come on Anthropic?). Instead this is a well thought out way of leveraging LLMs to do something which would otherwise probably not be deemed a reasonable enough effort.

I'm glad they included the rough cost as well. Crazy high, more than I can afford to be throwing at the wall to see what sticks, but still low enough to make sense over trying to hire developers for (even ignoring the timeline).

But it also highlights 2 really key things about current LLMs: the scaffolding can be just as valuable as the model & they still need someone able to figure out the right way to instruct and orchestrate them. Without the scaffolding the current models could never get close to handling something of this scale & quality. With the scaffolding you could probably get this to work okay enough even with a weaker model. On the orchestration side, Claude could help answer what good porting practices would be but it doesn't just get there itself, it requires hours of someone who understands the context of the project from bottom up and a clear understanding of what will/won't work to get the right scaffolding to do the job well.

Finally, it was an interesting dichotomy on presenting the port. On one hand it has been a bit opaque up until now. People saw the repo and there were some comments about testing the waters but then it suddenly shipped into production. On one hand that's awesome and I'm sure the reception here would be very different if there wasn't the "it's already been boringly shipped in Claude Code" shining result. On the other... I think I'll stick to using Bun as a personal tinkering tool for now. The velocity is so high I'm just not sure it'll land in a place I can rely on it st the speed of my org. Of course, that velocity is what has made Bun's success story and they should probably continue with it - I'm just looking forward to an LTS release :).