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

821–830 of 920 posts

Re: Claude Code uses Bun written in Rust now

#821

Post by rwz »

endospore wrote: post #213
rwz wrote: post #151

Earlier quoted context omitted.

The original code was one giant unsafe block with almost no tangible way to find or debug all the subtle memory bugs and leaks they had. Now it's smaller, faster and has fewer bugs. Also its every potential memory issue is neatly annotated by an unsafe block so you can go and refactor them out one by one with confidence. All this seems like a pretty huge improvement to me. Why is this an abomination in your eyes?

> The original code was one giant unsafe block True. > has fewer bugs Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them. > every potential memory issue is neatly annotated by an unsafe block "Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess wh…

> Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them.

I'm not sure I'm following what you're saying here. In the rewrite blog post it has been stated that the Rust port landed in a place where it passes 100% of the existing test suite and does so without some of the known memory leaks of the Zig version that they were aware of and didn't know how to address.

Sure, there's no guarantee that the port didn't introduce new bugs and most likely it did, but the 1.4 version has not been released yet, so I don't think a direct comparison of a long-time "stable" version and the just-landed full rewrite is meaningfully helpful.

> "Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.

But that just means that once you get rid of the unsafe block, you're pretty much guaranteed by the Rust compiler to be memory-safe. This means that all your potential memory landmines are annotated in the code and once you disarm them all, you're memory-safe.

I don't understand how what you're saying contradicts any of my statements.

> Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out.

Still easier than the Zig version, where all the same things you've mentioned apply, but also there's no visible indication of progress and issues are unmarked and could be pretty much anywhere.

> It's too early to declare it as anything remotely close to a win, optimistically saying.

Based on the rewrite blog post it's pretty clear that the Rust version is outperforming the Zig version by pretty much every measurable metric at this point.

I think the backlash is mostly focused on the ideological opposition to fully AI-authored 1MLOC+ PR approach they took.

Re: Claude Code uses Bun written in Rust now

#822

Post by HexDecOctBin »

Jarred wrote: post #727
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 (…

Grouped and arena allocations work really well in Zig. For awhile, we tried to use this pattern almost everywhere in Bun but it gets really tricky when there’s some GC-managed memory and you want to free things incrementally to reduce RSS. Also, using arenas for arrays that grow wastes memory a lot since it keeps every previous version around (mimalloc arenas are slightly better for this) Grouped allocations works es…

> using arenas for arrays that grow wastes memory a lot since it keeps every previous version around

Not if you use segmented arrays

https://danielchasehooper.com/posts/segment_array/

Re: Claude Code uses Bun written in Rust now

#823

Post by pier25 »

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…

This is the exact reason I stopped using Bun for new projects.

Terrible project governance.

TS 7 is a good example of what a responsible team that cares about their users should have done.

Re: Claude Code uses Bun written in Rust now

#824

Post by LtWorf »

whytevuhuni wrote: post #813
LtWorf wrote: post #811

Earlier quoted context omitted.

Rust doesn't check for logical errors, it checks for memory errors. So every single issue in an unsafe section is a potential CVE.

Of course, but even the presence of CVEs does not make software worthless, it just makes it worth less.

You don't seem to understand what I'm talking about.

bad axiom -> worthless theorem.

bad unsafe section -> verified safe section is actually not safe.

Re: Claude Code uses Bun written in Rust now

#825

Post by pier25 »

cush wrote: post #596
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…

There's literally nothing stopping anyone from continuing the Zig version if they want to

You mean except the bugs in the zig version and any future CVEs?

Re: Claude Code uses Bun written in Rust now

#826

Post by xedrac »

awesan wrote: post #785
kllrnohj wrote: post #618

Earlier quoted context omitted.

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

Realistically much of the most reliable software in the world was written in C. Robustness is more so a function of coding style and engineering practice than it is of the programming language chosen. Of course you could argue that on average, most programmers are not going to have the right practices and skill, so on average you should prefer Rust. But that's unrelated to the argument I was making, and in any case n…

Conversely, most of the high impact bugs are also written in C and C++, because they rely on "coding style and engineering practice" to be correct. Rust raises the floor on this by a lot.

Re: Claude Code uses Bun written in Rust now

#827

Post by davewritescode »

kburman wrote: post #9

Honestly, I initially thought rewriting an entire codebase with AI would be a huge mistake. After reading this, I'm starting to think I was wrong. If projects like Bun can be substantially rewritten and shipped to millions of users, it suggests we're entering a very different phase of software development. Today's AI-generated rewrites may not produce code that humans would consider high quality or maintainable. But…

Some of what you’re saying is likely true but quality is something that will never be optional. There is quantitative data suggest that LLMs perform better on higher quality code base which makes sense. Code that is well organized and coherent will make better use of the context window.

Software refactoring and tech debt is absolutely where LLMs will shine as is evidenced by the Bun rewrite.

Re: Claude Code uses Bun written in Rust now

#828

Post by whytevuhuni »

LtWorf wrote: post #824
whytevuhuni wrote: post #813

Earlier quoted context omitted.

Of course, but even the presence of CVEs does not make software worthless, it just makes it worth less.

You don't seem to understand what I'm talking about. bad axiom -> worthless theorem. bad unsafe section -> verified safe section is actually not safe.

I’ve understood the distinction. I just don’t like you equating “actually not safe” with “worthless”.

Re: Claude Code uses Bun written in Rust now

#829

Post by thewhitetulip »

simonw wrote: post #765
thewhitetulip wrote: post #680

Earlier quoted context omitted.

> The "General Labor Substitute": He rejects the idea that his employment forecasts are "doom marketing". Instead, he asserts that AI will act as a general substitute for human labor, noting that most software engineering could be entirely automated within 1 to 2 years When someone says all Software engg could be automated within 1yr they don't mean 'oh use our agents and keep human in loop' They mean 'AI superior th…

Have you watched the video where that was said, as opposed to just reading interpretations of it from people with their own assumptions? https://youtu.be/02YLwsCKUww?is=UsJrcLRgdSUd38Jt Here's a transcript: https://gist.github.com/simonw/0050b4ce40439b97598d4ffdb273d...

I summarised the transcript using LLM just like our AI overlords intended.

Re: Claude Code uses Bun written in Rust now

#830

Post by geon »

Ygg2 wrote: post #677
adwn wrote: post #667

Earlier quoted context omitted.

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.

> True, but unsafe let's you conjure up any lifetime you want The only thing unsafe does is let you have an unbounded lifetime. As I said, it doesn't check those: fn get_str (s: *const String) -> &'a str { unsafe { &*s } } https://doc.rust-lang.org/nomicon/unbounded-lifetimes.html > if you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker Yo…

> You don't disable anything. You wrote a "trust me compiler" block, and compiler trusted you.

That’s the same thing.

Post reply on HN