Live data from Hacker News

Claude Code uses Bun written in Rust now

simonwillison.net

611–620 of 920 posts

Re: Claude Code uses Bun written in Rust now

#611
post #266
post #91

Earlier quoted context omitted.

> 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?

Whole classes of bugs are fixed by safe rust. This is not safe rust. As a line-by-line translation with unsafe forced anywhere necessary to make it compile, this should result in no classes of bugs fixed by moving to rust.

Re: Claude Code uses Bun written in Rust now

#612

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…

Good thing there are tons of languages that do that out of the box, and which are frankly quite fast.

Re: Claude Code uses Bun written in Rust now

#613

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…

> Rust does this automatically. A garbage collected language does this automatically. Rust still requires thinking about and tracking memory lifecycles, but the borrow checker will complain and keep you from doing it wrong. That's why LLMs like Rust. It gives immediate feedback on what to fix. By-default constant reference parameters helps prevent major performance problems.

You're getting confused between lifetimes (the static analysis that prevents use after free and similar errors) and lifecycles (more commonly discussed under the heading of ownership) which determines when objects (and thus memory) are allocated and deallocated.

Ownership is automatic. You don't have to explicitly drop things when they go out of scope. (although the responsibility for that is split between the compiler and the library code).

Lifetimes are not automatic, but also have no effect on memory allocation. They are purely a static analysis path and you can make a functioning rust compiler that completely ignores lifetimes.

Re: Claude Code uses Bun written in Rust now

#614
post #357
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…

I have been working all day every day in Claude. I loathe their bug-ridden UI. Every release is a new crop of bugs, sometimes the old ones get fixed, usually not. Any kind of scrolling back, copying text, using their menu system - basically anything that isn’t typing characters has had/still has unaddressed bugs. OpenAI shipped a competitive model and I’m over in Codex now. I have yet to hit a bug. If you’re holding…

> I loathe their bug-ridden UI.

So weird that the same exact people telling you that programming careers are now obsolete are the same group who haven't been able to fix screen flickering bugs for like a year...

Re: Claude Code uses Bun written in Rust now

#615
post #554
post #477

Earlier quoted context omitted.

Which was completely bonkers -- it happened completely in the open, people were just outraged that something like this happens without asking them and not on a schedule they perceive as adequate. Most of them haven't really grasped what was happening and why. Many still don't.

> it happened completely in the open You don't create PRs like this when you're working "completely in the open" test ci #30412 No description provided. https://web.archive.org/web/20260509235415/https://github.co...

You don't test CI before you publish stuff?

Re: Claude Code uses Bun written in Rust now

#616

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…

> Rust does this automatically. A garbage collected language does this automatically. Rust still requires thinking about and tracking memory lifecycles, but the borrow checker will complain and keep you from doing it wrong. That's why LLMs like Rust. It gives immediate feedback on what to fix. By-default constant reference parameters helps prevent major performance problems.

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?

Re: Claude Code uses Bun written in Rust now

#617

Earlier quoted context omitted.

> 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 vta…

Re #3: vtable pointers aren't mutable...?

Re: Claude Code uses Bun written in Rust now

#618
post #376

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 (…

> 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?

Re: Claude Code uses Bun written in Rust now

#619

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…

Relative "number of unsafe keywords" or "lines inside unsafe blocks" isn't a good metric.

It's unsafe to call a C library that gives you a raw pointer, that can be a single line. It's unsafe to use that pointer, that could be a second single line. Carrying that pointer around, the data structures it's in, that's all safe, and doesn't implicate lifetime checking at all, so Rust will let you do silly things with the actual lifetime.

A better metric would be absolute unsafe keywords (because each carries a need to review), or "code in a module that uses unsafe anywhere" vs total code, because module boundaries isolate unsafe.

Re: Claude Code uses Bun written in Rust now

#620
post #55

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…

I guess the point is none of it matters, CC users didn't notice or don't care except an exceptionally small minority.

[dead]
Post reply on HN