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

631–640 of 920 posts

Re: Claude Code uses Bun written in Rust now

#631

Post by jackclayton »

kllrnohj wrote: post #618
awesan wrote: post #376

Earlier quoted context omitted.

Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things". You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (…

> You can just do that, and then Zig is really no less robust than Rust. If you just don't write bugs, then yes all languages are equally robust, including assembly. Zig, like C, is simply not a robust language. I don't know why this feels like something contentious? It's clearly not intended to be robust?

Above poster is talking about thinking in terms of grouped lifetimes and bulk allocations/deallocations, which is better for performance, and makes Rust borrow checking and other RAII style features pointless as they don't add any safety benefits. This video completely changed the way I think, and I subsequently moved on from Rust: https://www.youtube.com/watch?v=xt1KNDmOYqA

Re: Claude Code uses Bun written in Rust now

#632

Post by ozozozd »

gabrieledarrigo wrote: post #14

Bah. Personally my take on the entire affair is quite negative, whatever Jarred or Simonw says about it. I think Bun owned by Anthropic and the entire rewrite with AI is not the real point (even if it's quite interesting, though). My take is that Jarred, and Bun,didn't demonstrate a serious, adult approach, from "this is my branch, you are overreacting" message to just proceeding with a 1mil+ PR merged in less than m…

Serious adults?

They are in extremely short supply right now.

It’s a mix of serious-wanna be, quasi religious, quasi-technical people running the show right now.

I am so happy to I got to read about the 90s-2000s tech culture, and experienced the post-2008 startup culture.

Just about 10 years ago people were really serious, but chill-looking. Somehow that got flipped.

Re: Claude Code uses Bun written in Rust now

#633

Post by cyber_kinetist »

awesan wrote: post #376
mrothroc wrote: post #372

Drilling into the original article where Jarred explained the reasoning behind the change, It's pretty clear that under zig the team was doing things by hand that are automatic in rust. Humans and agents share one thing: they are both non-deterministic. He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people miss…

Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things". You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (…

I think the main issue is that Bun relies heavily on existing C++ libraries like JavascriptCore, and these require RAII and ref-counting semantics from C++ that are closer to Rust than Zig.

You could write a JS engine with Zig-like idioms (arena allocation, static initialization), but that would require re-writing the whole JS engine from the ground-up (though I would definitely be interested in it if someone actually tries to do it!)

Re: Claude Code uses Bun written in Rust now

#634

Post by ozozozd »

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…

This is a confusing comment because it’s the exact argument you would present against rewriting Bun to Zig, but you are arguing for one and against the other.

Re: Claude Code uses Bun written in Rust now

#635

Post by audunw »

kllrnohj wrote: post #618
awesan wrote: post #376

Earlier quoted context omitted.

Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things". You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (…

> You can just do that, and then Zig is really no less robust than Rust. If you just don't write bugs, then yes all languages are equally robust, including assembly. Zig, like C, is simply not a robust language. I don't know why this feels like something contentious? It's clearly not intended to be robust?

Zig is intended to be as robust as it can be as long as it doesn’t implicitly add code (no destructors that run code you didn’t explicitly call), or increase compiler complexity and compilation time.

I don’t think it makes sense to say Zig is or isn’t intended to be robust in general. Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more general proofs. It’s focused on eliminating one class of memory bugs in particular, exactly the class of bugs that are the biggest challenge for software like Bun, and other software with complex lifetimes (it originated from Mozilla and Rust is perfect for browsers)

Zig is intended to be robust for software like TigerBeetle, or the Zig compiler itself, where memory lifetimes are simple.

I’d say the focus on built in tests, fuzzing, debug memory allocators and safe mode shows that Zig is absolutely intended to be robust, within the scope of what the language aims to be. Far more than C itself or most of its popular compilers ever did.

Re: Claude Code uses Bun written in Rust now

#636

Post by aurareturn »

thewhitetulip wrote: post #627
aurareturn wrote: post #609

Earlier quoted context omitted.

I knew this was going to be the first reply. The answer is because you still need at least one human to develop and test any tool, integration, feature.

Why? Use agent bruh. Even the bun rewrite post said that agents do writing testing everything!!! Unless AI overlords lied and we do need humans

They had a human oversee the bun rewrite, didn't they?

Re: Claude Code uses Bun written in Rust now

#637

Post by ozozozd »

tbrockman wrote: post #492
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, pr…

So they had to rewrite Bun instead of Claud Code because they “already had bought Bun.”

This thread is filled with non-sequiturs.

Re: Claude Code uses Bun written in Rust now

#638

Post by egeozcan »

nicce wrote: post #150
zarzavat wrote: post #90

Earlier quoted context omitted.

Indeed as much I dislike the approach Bun took, at least the port appears to be working. TS7 is going to cause problems for downstream users because Go is the wrong language to use for something that has to run in WASM.

> TS7 is going to cause problems for downstream users because Go is the wrong language to use for something that has to run in WASM. Is there a huge need to run that typechecking on browsers?

I think running a typechecker on its target platforms has huge benefits.

Re: Claude Code uses Bun written in Rust now

#639

Post by ttflee »

cyber_kinetist wrote: post #633
awesan wrote: post #376

Earlier quoted context omitted.

Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things". You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (…

I think the main issue is that Bun relies heavily on existing C++ libraries like JavascriptCore, and these require RAII and ref-counting semantics from C++ that are closer to Rust than Zig. You could write a JS engine with Zig-like idioms (arena allocation, static initialization), but that would require re-writing the whole JS engine from the ground-up (though I would definitely be interested in it if someone actuall…

Why not using Swift?

Re: Claude Code uses Bun written in Rust now

#640

Post by snek_case »

aurareturn wrote: post #503
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?

Is Claude Code bottlenecked by performance? I think a JS runtime is fine because the ecosystem of tools is very large and plugins are easy.

People widely report very high memory and CPU usage.

Not all of the memory usage is the fault of Bun/JS. Some of it is likely memory leaks (holding on to data it shouldn't). However, some of the blame does go to using JS. In Rust you can tightly pack your data if you want to, but in JS you can't have nested structs for example. Every object referencing another object is two separate chunks of memory, each with a header, and a pointer from one object to the other. GCs also use more memory. The overhead adds up.

Building a CLI program in JS is a bad choice, and nobody should be defending this decision. Especially since Claude Code is very much able to write Rust code, and they've shown it can port code. Just port Claude Code to Rust directly.

Post reply on HN