Live data from Hacker News

Claude Code uses Bun written in Rust now

simonwillison.net

831–840 of 920 posts

Re: Claude Code uses Bun written in Rust now

#831

Earlier quoted context omitted.

Okay and as someone who would rather just straight up use cursor than claude code, I'd rather have my software not crash out on me every 5 minutes. What sort of self respecting dev purposely uses broken software? Even opencode (use it on nonwork computers) is fully better at this point.

Disingenuous, much? I've only ever had claude code crash once (after it decided to spawn like 12 subagents and got my laptop swapping like mad). If you're crashing every 5 minutes, either you have a cursed build, or you need to do a memtest.

It's not disingenuous, claude code has over 5k issues that are ignore plus thousands of more that were just silent closed.

This is a product by a company worth supposedly $1trillion and they can't even make one of their starship products not shit the bad within 5 minutes? These are the same engineers telling us for the last 3 years that coding is solved?

Like it's pathetic, and it's pathetic you're falling for it too. Have some standards, good grief.

Re: Claude Code uses Bun written in Rust now

#832
post #384

Earlier quoted context omitted.

> why not rewrite CC in a native language? It's hell to maintain for not much gain (for a use case like this at least). As much as it's become a meme, JS and web tech in general has become extremely portable and stable. I also don't think Anthropic bought bun to make their TUI better. They could have forked it, they bought bun because it incidentally was excellent for the way agents prefer to work and they wanted to…

I think they bought Bun because it was a supply chain risk for them. Their new flagship product (earning them billions of dollars in revenue per month ) was dependent on a platform maintained by a tiny startup. Buying Bun was a very rational way to reduce that risk, epically since it also got them some top tier engineering talent. Thinking about that further, I wonder if that was part of the rationale for switching f…

> But saying that out loud would be rude - they took steps to NOT openly criticize Zig, even after Zig's founder did not show them the same courtesy.

If this does not get Anthropic 'The Presidential Medal of Strategic Restraint' I don't know what will.

Re: Claude Code uses Bun written in Rust now

#833
post #85

Earlier quoted context omitted.

Anyone actually using it knows it is better. The C interop is so good that there is no use-case where C is the better option IMHO

You, by your own admission, haven't even written a single line of Zig despite having ~31 Zig projects on GitHub. I don't think your knowledge of the language is to be trusted in almost any capacity. This might seem harsh but I don't trust someone who's experience with a language amounts to slopping out 30+ repositories and not even engaging with the language normally.

I guess that since you haven't built the car you're driving, your opinions on it are null and void as well.

Anyone who actually believes that I can't have ANY sound opinion on Zig after 31 projects building with it should get their head examined for brain tumors. I mean, it's not like I have to deal with all the positive and negative effects of things written in it. It's not like I've had to solve problems in it that emerged when the LLM didn't do things correctly (and yes, I can tell when this is so, and not just when things are buggy). And it's not like I don't know (by heart, not by LLM) at least 15 other languages that I can draw on (C, for example, for which I not only got an A in a class at Cornell once, but was in fact the person with the highest score in a class of ~150 people... A perfect score, in fact) to form valid opinions in combination with how I see Zig working.

So please take your baseless skepticism and baseless assumptions and shove them up your ass, dude. I have work to do, and I'm far more capable of it now than I was, thanks to the LLM boost.

Re: Claude Code uses Bun written in Rust now

#834
post #821

Earlier quoted context omitted.

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

> In the rewrite blog post

They can't mention what they don't know. And that's the exact reason I'm against this: doing a port without being able to tell what is correct is asking for a disaster, obviously.

I've checked their posts and blogs for a few times, and I'm quite sure they don't know any of these to write about them.

> the 1.4 version has not been released yet

Let's hope the repeated delays (it was scheduled for last week) are not for quality issues, otherwise I'll only be half correct. It appears that all the MIRI errors are not stopping them though. (They have a script to run it but most probably it just fails and they don't care. Personally I'm not executing any of bun's code to avoid summoning nasal demons, so I actually don't know for sure)

> get rid of the unsafe block

Would be possible if they are not disregarding everything else going for numbers. E.g. they are actively increasing the unsafe surface by rewriting some code in SIMD C++ (https://github.com/oven-sh/bun/pull/33032). As if no Rust solutions already exist.

> Still easier than the Zig version

Well, this is true but only realizable if they know how to deal with the new problems emerging during the process. My current conclusion is that they don't.

> ideological

For me it's methodological as explained above.

Re: Claude Code uses Bun written in Rust now

#835

Earlier quoted context omitted.

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

Yeah, one needs to understand that "unsafe" does not mark which parts of the code are actually unsafe, it simply marks parts where the compiler ignores parts of its rule set. But the implications can crop up anywhere, there is no guarantee that a resulting use-after-free or similar can only happen inside the unsafe blocks. In short, if you use an unsafe block, then potentially any part of your code is unsafe.

Right, so if I understand correctly, to make the code fully safe, it can be impossible? Because you have underlying dependencies which are unsafe. The best you can do is make the handling of the unsafe as safe and as restricted as possible. But I can imagine some of these are way more difficult than others, and in programming the last 10% can be the last 90% of the work. Alas in terms of perceptions, the argument works well.

Re: Claude Code uses Bun written in Rust now

#836

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.

Sometimes being unserious is actually very serious. See current US administration.

Re: Claude Code uses Bun written in Rust now

#837
post #269
post #85

Earlier quoted context omitted.

You, by your own admission, haven't even written a single line of Zig despite having ~31 Zig projects on GitHub. I don't think your knowledge of the language is to be trusted in almost any capacity. This might seem harsh but I don't trust someone who's experience with a language amounts to slopping out 30+ repositories and not even engaging with the language normally.

By my own admission I wrote ~100K loc in zig-head. Having a background in linux kernel development of all things I can tell you that Zig is so much better than C or Rust, that I think linux kernel rush to rust is misguided.

Same. In fact I think going to Zig, possibly on the way to Rust, would have been a far more pragmatic route.

But I guess my opinion is null and void since I "slop-code"

Re: Claude Code uses Bun written in Rust now

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

Zig is always _less_ robust than rust. Even if you have a single allocation you can always forget to free it.

Re: Claude Code uses Bun written in Rust now

#839

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 was a recent post on here with a Claude Code issue I and others responses to. Specifically, the person from Anthropic who caused the issue replied on HackerNews. In it, he claimed he was the sole contributor and reviewer of the code into production, that he would “do better” in the future. Commenters were confused how a company like Anthropic could allow something like this occur and for an engineer to publicly admit a complete failure and negligence of build processes.

It’s clear seeing your post here a couple days later what’s going on. It’s deliberate. I can only speculate on their reasons why but it seems to be an intentional form of disrespect on the engineering culture. “Your norms, your work, your principles” mean nothing. We can spend money and invalidate your life’s work. We don’t need your consent or support. That’s my personal guess at a surface level.

Re: Claude Code uses Bun written in Rust now

#840
post #635

Earlier quoted context omitted.

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

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.

Static memory allocation is idiomatic in high-performance software. You do the same in C++ if you care about performance and reliability.
Post reply on HN