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

661–670 of 920 posts

Re: Claude Code uses Bun written in Rust now

#661

Post by aabhay »

MintPaw wrote: post #623
hugmynutus wrote: post #425

Earlier quoted context omitted.

This reads like cope because you're re-inventing RAII from first principles. I cannot take this seriously as tutorials on robust Zig Allocation Pools will store a deinit method for each item within the pool, so when the pool deinits, all internal objects can be deinit'd. That is just RAII & dtors from first principles, except with extra overhead of manually storing fat pointers yourself (and the bugs that come with t…

This is a general problem with destructors, you can't "batch delete" objects. To free a lot of stuff you're required to go pointer by pointer through the tree to clean up each object. To get real performance gains from pools you can't have per-object/subobject custom cleanup code.

Not necessarily. Drop semantics are just syntactic sugar, and can thus be aggressively inlined or auto vectorized by the compiler.

Re: Claude Code uses Bun written in Rust now

#662

Post by Yokohiii »

mrothroc wrote: post #413
latortuga wrote: post #400

Earlier quoted context omitted.

I seem to recall this Rust rewrite is all "unsafe" meaning it really doesn't automatically eliminate those issues.

Relevant passage from Jarred's post: "At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomati…

Why not porting JavaScriptCore?

Re: Claude Code uses Bun written in Rust now

#663

Post by WD-42 »

Yokohiii wrote: post #659
KingMob wrote: post #656

Earlier quoted context omitted.

A casual read of TigerBeetle's practices makes it clear they're doing some very unusual things, both in their memory allocation strategy and in their testing/verification. Despite TigerBeetle being one of the highest-profile remaining Zig projects, I actually don't think they're representative of the average Zig project at all.

Can you elaborate on the unusual part?

All necessary memory is allocated at initialization. The application is not allowed any allocations during it's normal runtime. This is how it avoid memory bugs.

Not a lot of people write programs this way.

Re: Claude Code uses Bun written in Rust now

#664

Post by kingds »

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.

it does seem to be very much bottlenecked by performance, yes. very slow to start up, for example.

Re: Claude Code uses Bun written in Rust now

#666

Post by thewhitetulip »

aurareturn wrote: post #660
thewhitetulip wrote: post #650

Earlier quoted context omitted.

that's the hypocrisy I was pointing out. Lol For their work they extensively test using humans with deep expertise But while marketing they say just vibe code bruh And here they can't even rewrite CC in rust? Why not! Use 1000000 agents!! Write it in platform specific binary! SAAS is dead, that's what he claimed. So what's stopping him from writing the harness in Rust or C than ReactJS?

What hypocrisy? Anthropic never said you don't need a human anymore.

I think we are not living in the same universe if you claim this. And I can't speak with someone who doesn't live in the same universe

Re: Claude Code uses Bun written in Rust now

#667

Post by adwn »

Ygg2 wrote: post #654
gcr wrote: post #616

Earlier quoted context omitted.

It’s my understanding that bun was ported to unsafe rust, so even these gains would require additional effort on the team’s part, right?

Unsafe Rust doesn't automagically disable typesystem (& borrow checker, but lifetime are a sort of types). Once raw pointer is turned into a T, &T or &mut T, the borrow checker is on.

True, but unsafe let's you conjure up any lifetime you want, or any lifetime necessary to satisfy the lifetime requirements in safe code. If you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker – including in safe code – until you've checked and verified the correctness of all unsafe blocks.

Re: Claude Code uses Bun written in Rust now

#668

Post by kllrnohj »

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…

> You could write a JS engine with Zig-like idioms (arena allocation, static initialization)

Arena allocators & static initializers are not novel. You'll find them in high performance C++ projects as well, such as LLVM or JavaScriptCore. But arena allocators have the quite significant limitation that they only help when everything being allocated in them have approximately the same lifetime. So they don't help when you need to allocate memory to provide the native implementation of a JavaScript object, for example (eg, FFI).

Re: Claude Code uses Bun written in Rust now

#669

Post by yathaid »

dirtbag__dad wrote: post #585
raincole wrote: post #451

Earlier quoted context omitted.

This is the correct approach (I dare to say the only correct approach) when porting to another language. You can examining the architecture later.

If you can lock down a test suite that ensures parity, then who cares what shape the lift ultimately looks like. A full rewrite in different language that fails to be idiomatic is a step backward operationally, even if you stand to gain on issues the new language just eats for free

I like your fair-mindedness but for folks who are anti-LLM-anything, your argument is not the point.

Evidence: see the amount of nonsense in the postgres rewritten in Rust story - https://news.ycombinator.com/item?id=48841676 where there are two contradictory claims made:

"postgres is so stable I will never trust a rewrite."

"covering 100% of postgres regression suite doesn't guarantee you have replicated every behavior."

Folks who are okay with LLMs think the regression test suite is the spec and is the guarantee of stability. How else can it be? If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you?

Folks who are against seem to imagine a platonic ideal of PG which conveniently is the original PG implementation by tautological definition. So no rewrite can ever meet their bar.

Re: Claude Code uses Bun written in Rust now

#670

Post by adwn »

nestorD wrote: post #622
gchamonlive wrote: post #424

Earlier quoted context omitted.

> Rust does this automatically. It removes an entire class of errors from his backlog. Even with the huge amount of "unsafe" rust currently in bun? https://news.ycombinator.com/item?id=48967630

Fun fact, unsafe does not let you turn off the borrow checker in Rust: https://steveklabnik.com/writing/you-can-t-turn-off-the-borr...

"Fun fact", it lets you largely circumvent the borrow checker by creating arbitrary lifetimes: https://news.ycombinator.com/item?id=48974824
Post reply on HN