Live data from Hacker News

Claude Code uses Bun written in Rust now

simonwillison.net

331–340 of 920 posts

Re: Claude Code uses Bun written in Rust now

#331

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.

I'm confused as well, could someone who knows how TUIs work explain what's the point of React-style diffing in this context? I thought you need to clean and full redraw if anything changs anyways?

> I thought you need to clean and full redraw if anything changs anyways?

Unless you use an ancient teletype, you don't have to redraw everything. That would make any interactive applications way too slow/flickery.

You can move the cursor arbitrarily in the terminal and start overwriting characters from there. So you need to track state to know what is "dirty" and needs refreshing. Occasionally you issue a full redraw to catch missed artifacts left behind or when the terminal is resized (SIGWINCH).

Re: Claude Code uses Bun written in Rust now

#332
post #236

Earlier quoted context omitted.

It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question. They chose it early on, it works, and it makes obscene amounts of revenue. End of story. That doesn't mean it was the "greatest" choice, or has a perfect technical architecture. Rewrites are never easy, even the bun rewrite. But a non-UI developer tool with a rig…

> It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question. Your counter argument would be valid for a 2000 or a 2020 business decision about some tech stack. But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build w…

> by making it cheap and fast to build whatever you like automatically.

Cheaper, but not free (if you don't buy into the marketing promises too much). The bigger the project, the bigger the cost, even with a discount.

At the same time, the early versions weren't very good and you can be sure that any rewrite will also need to be similarly iterated upon until it is also good enough and polished.

If you do that and don't spend enough effort on making it be something polished --> your competitors have a better product and you lose.

If you pause feature development to give enough effort to the initiative, you don't get to add new features quickly enough --> your competitors have a better product and you lose.

Maybe their priorities lay elsewhere, like how I've noticed that the desktop app version of Claude Code has gotten both faster (no 2-4 second lag when switching conversations), more stable and usable over time, to where I enjoy using the models because of it, not in spite of it (though not that they haven't had bumps along the way, like that one cache invalidation issue, or how people didn't like the auto accept timeout thing). I don't doubt that you can get pretty far with gradual patches and improvements, instead of only big rewrites.

Honestly it's really cool for me to see Kimi having their own CLI too, same with OpenCode, Pi, Hermes (well more of an agent than just a coding harness but you get the idea) - there's so many competing solutions out there, each good or bad in unique ways.

Just wish we'd see similarly many GUI solutions, for now OpenCode GUI seems like the one I've settled on (cross platform and supports most models), though it's not exactly ideal either (feels a bit barebones, especially in regards to sub-tasks and progress/plan tracking, even ZCode seems a bit better in that regard, it was actually surprisingly good after they pushed out some updates).

Re: Claude Code uses Bun written in Rust now

#333
post #252

Earlier quoted context omitted.

Why are you implicating ghostty? Have you compared its CPU usage to any other terminal?

Of course I have. If I see ghostty constantly consuming the most energy and helping reduce my battery life to barely 2 or 3 hours, the first thing I'm going to do is switch terminal to see if I can improve that situation. The built in terminal and WezTerm have been fine and I've had much more reasonable battery life since. This does not even speak to it pegging my CPU and keeping the fans running on full blast even w…

Same. I really want to file a proper bug report for this but I haven't been able to really dig into the details and the last thing I want is a "ghostty is a cpu hog" kind of report without useful info on how to debug that.

Re: Claude Code uses Bun written in Rust now

#334
post #37

Earlier quoted context omitted.

You can install it now we with bun upgrade —-canary it something along those lines.

I think you’re missing a word or two.

It's extremely obvious what they meant, even if it/or wasn't a common phone autocorrect typo.

Re: Claude Code uses Bun written in Rust now

#335

Earlier quoted context omitted.

Seems to be working just fine though? And like, this is just the beginning of the port. They did a mechanical port basically line by line, next step is to make it idiomatic rust. I thought by now people would’ve learned to stop betting against this rewrite.

> next step is to make it idiomatic rust You can tell what will happen when they release it before sorting out all the new bugs introduced by the not-exactly-line-by-line port.

Sorry you think they’re not going to continue developing and improving bun and making it more idiomatic?

Given the success of the port so far and the fact that CC is now running on rust Bun, that seems highly unlikely to me.

Re: Claude Code uses Bun written in Rust now

#336

Earlier quoted context omitted.

First, yes, the demand to be able to code natively in a browser is, I have reason to suspect, very large. It's just difficult to measure demand when nobody has ever offered a really compelling product. In engineering terms it's like getting a full-scale reading. The real level could be 1% above a full-scale reading, or the real level could be 100x higher than the full-scale reading. Secondly, WASM isn't the right tar…

> If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates. calibre (with python+Qt) begs to differ. And I believe VLC runs on every current platforms. There's also Code::Blocks and Blender. Cross-platform UI is not rocket-science.

All great examples, but ones that do require installation. Their website is just where you download the product, I'm talking about making the website the product.

Re: Claude Code uses Bun written in Rust now

#337

Earlier quoted context omitted.

Zig is a DOA language for other reasons though. The reason why Rust enthusiasts act so morally superior is because they are: > Rob Pike, an unsafe guy, may insist that a small language and garbage collection are enough. But the typesafe visionary Grzegorz Wielbodłąński understands the deeper truth: every invalid state permitted by a compiler is a tiny act of civilizational sabotage. https://x.com/typememetics/status/…

> There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic. This is where I’ve arrived too. After nearly 20 years of programming I feel done with leaving foot guns lying around. Languages that are full of t…

yeah rust has no footguns. just dont try to mix clone with iter.

Re: Claude Code uses Bun written in Rust now

#338

Earlier quoted context omitted.

> It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question. Your counter argument would be valid for a 2000 or a 2020 business decision about some tech stack. But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build w…

Yeah, this is what I’m trying to get at. There’s two arguments in competition: 1. LLMs make it cheap (in the time sense) and easy to build 2. Rewrites and/or writing something in a native app or program is harder and more time consuming I think I am willing to take it as an axiom that a native version of CC would be superior from a user perspective. Performance, etc. I just don’t see how one can say that building thi…

> I just don’t see how one can say that building things reliably good is easy now when the company providing these tools can’t even do it well.

I don't know how you can't see it, to me it's blindingly obvious: risk aversion.

Let's say the risk for a problem is 1%; hell, let's put it at 0.1% even. For a company at this scale even that amount of risk is too much.

I trust Opus/Fable to drive prod database migrations and backfills. I don't trust it with our financial ledger. I trust it with part of the infra. I don't trust it with backups. Etc.

You and others are arguing against a premise that nobody defended, namely "Claude can rewrite everything, for free and with zero mistakes". A bit of a straw man, don't you think?

And that's not even touching the fact that writing a GUI app is difficult for LLMs due to difficulties in it getting feedback and a "feel" whether it delivered what was asked (though I know people are working on it).

> I think I am willing to take it as an axiom that a native version of CC would be superior from a user perspective. Performance, etc.

How does that follow, and from where? I never once noticed any visual jank/lag in the TUI; not in iTerm2, not in Kitty, not in Alacritty, not in WezTerm and not in Ghostty. And even if we exclude those two, me and many other devs are quite fine with a TUI and don't miss a GUI program for everyday coding.

Not saying that our preference is superior -- but it'd be strange to blatantly claim: "for dev purposes, GUI > TUI/CLI".

Re: Claude Code uses Bun written in Rust now

#339
post #271

Earlier quoted context omitted.

I think you're missing group 3, which is the "assume bad faith and/or bad outcome from any possible change to anything, and especially changes to open source projects that can be interpreted as exogenous, e.g. from an acquirer, and especially if that acquirer is a gigantic commercial entity." There are not nearly enough disenfranchised Bun-on-Zig contributors to make a dent in this conversation. There are lots of Gro…

I think most of the naysayers are in group 3 because there’s a lot of anger but never a single link to a blog post or analysis done by anyone to demonstrate a regression. not one. There are some that analyzed the quality of the initial rust code and use of unsafe but Claude has been chewing through those as I understand.

It was a PR issue more than anything else. It is also a proxy for Pro AI and Anti AI sentiment.

And for most part I don't think it was communicated well apart from the last blog post.

Re: Claude Code uses Bun written in Rust now

#340

Earlier quoted context omitted.

> It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question. Your counter argument would be valid for a 2000 or a 2020 business decision about some tech stack. But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build w…

> by making it cheap and fast to build whatever you like automatically. Cheaper, but not free (if you don't buy into the marketing promises too much). The bigger the project, the bigger the cost, even with a discount. At the same time, the early versions weren't very good and you can be sure that any rewrite will also need to be similarly iterated upon until it is also good enough and polished. If you do that and don…

Can't have been that cheap if they thought buying Bun for an undisclosed amount of money was cheaper.
Post reply on HN