Live data from Hacker News

Claude Code uses Bun written in Rust now

simonwillison.net

261–270 of 920 posts

Re: Claude Code uses Bun written in Rust now

#261
post #53
post #30

Earlier quoted context omitted.

From the article: > For me this outputs Bun v1.4.0 (macOS arm64). The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version. Which is still true as I write this comment.

The code is on GitHub in the "main" branch, it's only unreleased in that it hasn't been tagged with a version number yet.

If it hasn't been tagged with a version yet, how do you know (or what makes you think) it's the same as this 'v1.4'?

Re: Claude Code uses Bun written in Rust now

#262
post #152

Earlier quoted context omitted.

An interesting tidbit is that large parts of the original Bun source code was a line-by-line port of esbuild from Go to Zig (mentioned here: https://bun.com/blog/bun-in-rust ), tbh this lowered my respect for the project a bit (a line-by-line port simply isn't as interesting as original work), and it might also explain the subpar Zig code quality (a line-by-line port from Go to Zig simply won't result in idiomatic Zi…

I read your link, written by Bun's author and totally get his thinking. In the current world of cyber weaknesses everywhere, infrastructure must be solid and rust is a better choice than zig for something like bun. In other words, bun is not a demo of zig programming that happens to do useful things. Bun does useful things, and must do them securely. That is its number one priority, language is secondary, inasmuch as…

Are you really "doing things securely" when you use as many unsafe blocks as the Rust port of Bun does?

Re: Claude Code uses Bun written in Rust now

#263

Earlier quoted context omitted.

So, you have a vibe-coded TUI which happens to work, and then, as a workaround you vibe-translate its engine to make it more performant. Where does that leave you ? Basically, fully dependent on AI to fix whatever breaks. Workaround on a workaround is the way I see it, and it aligns with the AI design mentality in general. For a variety of usecases, this might still be a win in terms of overall cost. But, for softwar…

> for sw that is intended to be built to last, I dont see this working out. the era in which the tech industry built software to last was over long before LLMs, especially VC-backed startups.

Did it really exist? I remember buying games on discs as a kid that had bugs in them that prevented you from actually finishing the game at all.

I'm pretty sure "built to last" was only ever more true in specific contexts, and wasn't particularly more true than today.

Re: Claude Code uses Bun written in Rust now

#264

Earlier quoted context omitted.

Except that it hasn’t yet hit the real world, the live release is still 1.13.4, the last Zig version. Anthropic does not operate in the real world.

The canary build has been Rust for over a month, available to anyone. In that time it has been used in production for Claude Code and Prisma Compute.

Not sure why this purely factual post got downvoted. Upvoted it.

Re: Claude Code uses Bun written in Rust now

#265

Earlier quoted context omitted.

The criticism didn't appear to me to be that the solution didn't work, just that many of the working solutions we are selecting are dangerously overcomplicated due to shortsighted decisionmaking. The benefits of throwing redundant stacks of abstraction atop each other in terms of time to market are questionable, and obviously absent in every other metric.

So, you have a vibe-coded TUI which happens to work, and then, as a workaround you vibe-translate its engine to make it more performant. Where does that leave you ? Basically, fully dependent on AI to fix whatever breaks. Workaround on a workaround is the way I see it, and it aligns with the AI design mentality in general. For a variety of usecases, this might still be a win in terms of overall cost. But, for softwar…

That does seem to be the way many use it. I'd be very surprised if they didn't have to insert a rule to prevent opus from constantly asking why they didn't just use ncurses. I just asked sonnet for design options for a tui to onteract with llms to perform sw dev tasks. After describing the tui it immediately suggested ratatui and crossterm as the tech stack. I feel like they must have ignored even the advice of their own llm to come up with this solution.

Edit, the sonnet question shouldn't be taken as proof, it knows I'm a rust dev.

Re: Claude Code uses Bun written in Rust now

#266
post #91
post #18

Earlier quoted context omitted.

It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge. I feel weird having to defend reality; reality being that it was merged nearly 2 months ago and tons of people have had their pitchforks out without a shred of actual evidence that this made bun worse in any measurable way. But they still insist it was a mistake. I’ve never met Jared or the bun team but I…

> that this made bun worse in any measurable way Issues on GitHub was mass closed claiming zig is no longer relevant without fixing the real issues.

Whole classes of bugs WERE fixed by moving to rust. wouldn’t that result in mass closures of classes of bugs that were no longer relevant in rust? What would you prefer?

Re: Claude Code uses Bun written in Rust now

#267
post #233

Earlier quoted context omitted.

Why would rewriting Claude code, an app which probably has 30-40 (I might be significantly underestimating) extremely active contributors be easier than rewriting Bun, which has fewer contributors and almost certainly also less lines of code?

Because I’ve been told that Fable can do anything :-) My question is moreso “why was it ever JS in the first place” & the cost of a native rewrite would be cheaper than acquiring Bun no matter how you shake it

>Because I’ve been told that Fable can do anything

I hear some version of this anecdote constantly

yet despite using all these prompting tools since 2019 I have never once heard a lab or professional say “x model can do anything”

Can you provide me whatever specific source you heard for this?

Re: Claude Code uses Bun written in Rust now

#268
post #50
post #9

Honestly, I initially thought rewriting an entire codebase with AI would be a huge mistake. After reading this, I'm starting to think I was wrong. If projects like Bun can be substantially rewritten and shipped to millions of users, it suggests we're entering a very different phase of software development. Today's AI-generated rewrites may not produce code that humans would consider high quality or maintainable. But…

That sounds like a massive waste of finite energy and compute resources.

That's like saying let's stay with horses.

We'll develop faster and better tech. We'll find resources to feed that. Use that to build better. Access better resources. We'll mine asteroids. We'll harness much more from the sun. The factory must grow.

Re: Claude Code uses Bun written in Rust now

#269
post #85

Earlier quoted context omitted.

Anyone actually using it knows it is better. The C interop is so good that there is no use-case where C is the better option IMHO

You, by your own admission, haven't even written a single line of Zig despite having ~31 Zig projects on GitHub. I don't think your knowledge of the language is to be trusted in almost any capacity. This might seem harsh but I don't trust someone who's experience with a language amounts to slopping out 30+ repositories and not even engaging with the language normally.

By my own admission I wrote ~100K loc in zig-head. Having a background in linux kernel development of all things I can tell you that Zig is so much better than C or Rust, that I think linux kernel rush to rust is misguided.

Re: Claude Code uses Bun written in Rust now

#270

Maybe I’m taking crazy pills, but I’m still stuck on “why the hell does a TUI need to run in terminal React by way of JavaScript” The fact that Anthropic felt the need to buy a runtime so they could make their TUI better speaks more to the quality of engineering than anything else IMO. If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.

So the code for the web, the desktop app, and the cli where largely similar.
Post reply on HN