Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Code uses Bun written in Rust now

simonwillison.net

Post reply on HN
Print view View original

491–500 of 920 posts

Re: Claude Code uses Bun written in Rust now

#491

Post by vmg12 »

wild_egg wrote: post #462
vmg12 wrote: post #412

Earlier quoted context omitted.

Drawing to the terminal / rendering / whatever, this is all arguing semantics and very uninteresting and not insightful. > they need a high powered game engine rendering loop Don't believe the bs on twitter. Claude code source was leaked, there is no high powered game engine rendering loop. > It needs to stream text to stdout These apps are doing real work taking text that is streaming in and doing syntax highlightin…

There are two different arguments here. > These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown. The first argument is that these are expensive operations. They are not. And the second argument is the assumption that these are desirable things for an agent system to be doing. That's a personal preference but, personally, I don't want t…

The argument is that doing it all on a single thread will result in high cpu utilization and that is what makes the power usage spike and the pc feel hot. Thats it.

A lot of people go “js is bad” reflexively and they are right for the wrong reasons. Its not because js (specifically v8) is slow. I have many websites and web based apps open and none fuck up my laptop as hard as claude code.

Re: Claude Code uses Bun written in Rust now

#492

Post by tbrockman »

GuB-42 wrote: post #209

Why all the mess with Bun? Couldn't they have rewritten Claude Code in Rust directly? No more need for a JS runtime, better performance, etc... If their agents can do Zig to Rust, why not JS to Rust?

In isolation, yes, that does seem like it would have been the better decision for Claude Code, but it also would have severely diminished the value of their Bun/oven.sh acquisition.

Claude Code isn't the only user of Bun (it's probably not even the only user of it internally at Anthropic), and this way they get to keep the Javascript runtime (and other tooling) that their coding models may one day, if not already, prefer to use when given the opportunity. For those kind of apps, you'll probably also eventually find that--what do you know!--Anthropic also has their own cloud offering (instead of Bun being the one to build one) that specializes in running and managing those applications for you. Even if all they get is a community of developers that choose to use Bun over other options, that gives them power and seats at tables they wouldn't have if they just rewrote Claude Code in Rust.

That'd be my best guess, anyhow.

Re: Claude Code uses Bun written in Rust now

#493

Post by coldtea »

squidbeak wrote: post #459
piker wrote: post #453

Earlier quoted context omitted.

Right now? Zero. In 2 years? A well-engineered TUI could be the difference between the Blackberry and the iPhone for all we know.

Perhaps over those two years they'll reach the same conclusion and change the engineering?

Perhaps by then it can be too little, too late, too?

Re: Claude Code uses Bun written in Rust now

#494

Post by root_axis »

Aeveus wrote: post #175

Anecdotal, but I’ve been getting segfaults in Claude Code. I run inside Kitty tabs, and the entire tab becomes unusable when this happens. No response to inputs at all from that point. When this happens, a link shows up to report the issue. It’s not clickable (likely due to the segfault), and perhaps more important: it’s encoded, so you can’t see what you would be sending in your report. Hope it gets better.

Same experience I have with bun in general. As an idea, it's the absolute best js runtime by a very large margin, but in terms of stability it's terrible and segfaults 20x as much as node (I base that number on newrelic telemetry)

Re: Claude Code uses Bun written in Rust now

#495

Post by kccqzy »

javawizard wrote: post #362
mort96 wrote: post #180

Earlier quoted context omitted.

What makes you think it's a segfault? Does your shell print "Segmentation fault"? If so, you should be back at your shell and you should be able to recover the tab by typing 'reset' + enter (even if you can't see anything as you're typing it). If nothing prints "Segmentation fault", this just sounds like a hang

I just had this happen today. It was indeed a segfault. From what I could tell it looked like it was in JS code that had been JIT compiled. I haven't attempted to troubleshoot further beyond setting all my future Claude Code instances to pipe their stderr to disk so that I don't lose the stack trace next time.

Bun does not have its own JIT compiler. Bun uses JSC made by Apple. So your blame should be directed to Apple.

And I can believe you because I’ve seen JavaScript-heavy Safari tabs crash.

Re: Claude Code uses Bun written in Rust now

#496

Post by Philip-J-Fry »

vips7L wrote: post #415
Philip-J-Fry wrote: post #387

Earlier quoted context omitted.

Segfaults were a thing with the Zig version. Purely based on the fact it's a line by line translation of the Zig code to unsafe Rust, all the Zig code that caused segfaults is going to also cause segfaults in the Rust version. The Rust code won't fix it until they get to the point of refactoring it into idiomatic and memory safe Rust.

But if the segfaults are new that implies it’s from the LLM no?

Who said they're new? Also, you can encounter new segfaults in a codebase just by executing code paths you haven't seen before.

Re: Claude Code uses Bun written in Rust now

#497

Post by kccqzy »

endospore wrote: post #208
daishi55 wrote: post #140

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.

But Bun did not even release a new version of Bun written in Rust yet. It was still a canary version.

Re: Claude Code uses Bun written in Rust now

#498

Post by jstimpfle »

hugmynutus wrote: post #452
jstimpfle wrote: post #432

Earlier quoted context omitted.

I've argued elsewhere some things that are wrong with RAII and C++ objects in general. Here I would just like to mention that if you have to rely on "de-virtualization" passes, you're in a miserable situation architecturally. If you have code where the overhead of virtual function calls might be too much to pay, don't do virtual functions then. End of story. To deconstruct a pool of objects, I don't see what should e…

> I don't see what should ever be wrong with a function pointer. [...]Care to explain what's the issue here? 1. You're writing code you don't have to 2. That adds runtime overhead 3. That when you screw up has non-trivial security & resource management side effects This is objectively indefeasible in nearly any vaguely professional context.

1. No, you're not writing code you don't have to. It's not different to implementing this as non-virtual methods, in fact I'd argue doing simple functions is more straightforward.

2. And the code being compiled is abstract & generic, it won't be instantiated for every type and bloat the executable or instruction cache.

3. Security concerns: With C++ virtual methods every object carries a mutable pointer too (to a vtable containing function pointers). What resource management side effects please?

Re: Claude Code uses Bun written in Rust now

#499

Post by [deleted] »

switz wrote: post #236
weakfish wrote: post #212

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.

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…

[deleted]

Re: Claude Code uses Bun written in Rust now

#500

Post by vips7L »

switz wrote: post #236
weakfish wrote: post #212

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.

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…

Any choice would have made obscene money in this market. It doesn’t make it a good choice.
Post reply on HN