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

741–750 of 920 posts

Re: Claude Code uses Bun written in Rust now

#741

Post by kzrdude »

ozozozd wrote: post #632
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.

Mario Zechner's talk "Building Pi in a World of Slop" is a good listen, on the topic of adults in a "world of slop". https://www.youtube.com/watch?v=RjfbvDXpFls

Re: Claude Code uses Bun written in Rust now

#742

Post by IshKebab »

arikrahman wrote: post #672

Why not just use Deno that's made in Rust and also has safety in mind?

Yeah I'm also wondering what the point of Bun is when Deno already exists. Especially since it added Node compatibility. Genuine question, why should anyone use Bun if they're already using Deno?

Re: Claude Code uses Bun written in Rust now

#743

Post by Conscat »

jstimpfle wrote: post #683
kllrnohj wrote: post #617

Earlier quoted context omitted.

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

Of course they are. The pointers to the vtable are part of the object. They aren't mutable fields as per the language, but for security concerns it doesn't matter what the language thinks. Being part of the object, the vtable pointer has to live in a writeable memory mapping (like stack / heap).

Clang pointer authentication makes any type of vtable attack impossible in C++.

Re: Claude Code uses Bun written in Rust now

#744

Post by NewsaHackO »

firesteelrain wrote: post #95
afavour wrote: post #84

Earlier quoted context omitted.

That seems illogical to me. We’re only allowed to have one objection to a project and once that’s used up we can’t air another? FWIW I don’t think people have forgotten the original objection either!

You can; it feels contrived and very social justice warrior/anti Anthropic (which on HN is in of itself almost a meme now). The main reason was because of the blanket AI move which I could understand.

People are now saying poor communication because the Bun creator was not able to see the future and didn’t immediately flag his draft rewrite as the next big thing when he started working on it.

Re: Claude Code uses Bun written in Rust now

#745

Post by endospore »

atonse wrote: post #271
estearum wrote: post #102

Earlier quoted context omitted.

I think you're missing group 3, which is the "assume bad faith and/or bad outcome from any possible change to anything, and especially changes to open source projects that can be interpreted as exogenous, e.g. from an acquirer, and especially if that acquirer is a gigantic commercial entity." There are not nearly enough disenfranchised Bun-on-Zig contributors to make a dent in this conversation. There are lots of Gro…

I think most of the naysayers are in group 3 because there’s a lot of anger but never a single link to a blog post or analysis done by anyone to demonstrate a regression. not one. There are some that analyzed the quality of the initial rust code and use of unsafe but Claude has been chewing through those as I understand.

https://github.com/oven-sh/bun/issues/30719#issuecomment-446...

Personally I chose not to disclose my findings in public to avoid this kind of outcome. Having a good laugh with others is not as important as keeping the result of this experiment undisturbed.

This also eliminates the chance of another round of marketing of LLM ability based on actual human contributions and I suggest everyone who is able to analyze the code to do the same - so that they cannot misattribute our ability to LLMs.

Re: Claude Code uses Bun written in Rust now

#746

Post by coldtea »

pdimitar wrote: post #581
coldtea wrote: post #489

Earlier quoted context omitted.

How is that relevant to my response? The argument I responded to argued that cost might be the prohibiting factor. I'm saying that for them, the costs mentioned are negligible.

I didn't claim that the cost is the prohibiting factor at all. Obviously they gave Jarred free Fable access and to do as his pleases. The cost was an FYI tidbit and nothing more. What I argued was that you seemed to have been arguing an extreme point i.e. LLMs can one-shot stuff in any PL and that it does not matter in what PL they'd rewrite Bun. If I misunderstood -- my apologies.

Well, I never said anything about one-shotting it.

What I said is, those AI companies push LLMs as the replacement of programmers, that can do everything code-wise, say their programmers "don't write code anymore" etc.

So how come they can't have the LLM write something better than "react for cli" for their flagship agent product?

Re: Claude Code uses Bun written in Rust now

#747

Post by Ygg2 »

ttflee wrote: post #639
cyber_kinetist wrote: post #633

Earlier quoted context omitted.

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?

Andreas Kling talked about it. It boils down to C++ interop sucks (no surprise for lang made by Apple), ecosystem is tiny, Rust works well enough with LLMs.

https://youtu.be/DbHjKi_jASY

Re: Claude Code uses Bun written in Rust now

#748

Post by vintermann »

hresvelgr wrote: post #722
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. That's just it, using Zig required more rigorous engineering than the Bun team were capable of.

It matters what software you're writing. When it's a JavaScript runtime, it's not as if you can get away with preallocating all the memory you'll need like some games used to do.

Re: Claude Code uses Bun written in Rust now

#749

Post by josephg »

NohatCoder wrote: post #733
dwattttt wrote: post #619

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.

> In short, if you use an unsafe block, then potentially any part of your code is unsafe.

The way I think about it is that the unsafe keyword is a promise that you’re going to maintain the safety invariants yourself, manually. The program is memory correct if it correctly maintains a certain set of invariants. Unsafe punts responsibility over those invariants to the programmer. If you use unsafe and mess up, the program may be in an invalid state. Yes - it might crash, anywhere. But the bug is still almost always in an unsafe block.

It’s often possible to make fully safe wrappers around unsafe code which maintains all those invariants manually. (Either statically or dynamically.). A lot of the rust standard library does this. For example, Vec, Box and slice all use unsafe code internally to create safe APIs.

Re: Claude Code uses Bun written in Rust now

#750

Post by raverbashing »

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…

> 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 missed things.

Yes, and again the "you're holding it wrong" people or "you are not a good enough developer" people will try to do juggling with a chainsaw and lose a couple of fingers in the process

Claude Code's endorsement (and real-world testing) speaks louder than internet discussions that are at this point 30 years old (and probably more)

Post reply on HN