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

751–760 of 920 posts

Re: Claude Code uses Bun written in Rust now

#751

Post by vintermann »

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)

Could you actually? That seems like a bad fit for a JS engine to me. Predictable memory requirements are great when you can have them, perhaps you can avoid complexity then, but for a JS engine?

Re: Claude Code uses Bun written in Rust now

#752

Post by endospore »

d5lt5 wrote: post #679
endospore wrote: post #213

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…

For someone who is not a rust dev, would you mind giving me an example of this: "Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them."

Aw I feel quite sorry for using the word "demonstrable" while not intending to demonstrate anything, in order to avoid any contributions to the project. I apologize for that.

That being said I've found a case that doesn't do much harm even if it's fixed, and is technically not my contribution. You may take a look at that:

https://github.com/oven-sh/bun/pull/30794

Re: Claude Code uses Bun written in Rust now

#754

Post by boutell »

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…

I thought that this was just an initial translation to unsafe rust in which they haven't actually gained any of those benefits yet, although presumably they can go there quickly now.

Re: Claude Code uses Bun written in Rust now

#755

Post by pdimitar »

coldtea wrote: post #746
pdimitar wrote: post #581

Earlier quoted context omitted.

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?

My only half-decent guess: they deem it too big and risky and believe they'll lose revenue while working on it and ironing out remaining kinks.

Claude Code is likely not well-specified and it's a product of rapid iteration and now nobody really knows how the whole thing works. LLMs don't do well when requirements are muddy.

Re: Claude Code uses Bun written in Rust now

#756

Post by perching_aix »

slopinthebag wrote: post #571
scrollaway wrote: post #566

Earlier quoted context omitted.

I have ~24 years of experience coding and the LAST thing I think about when opening claude code is "why is this written in react". Tell you what I sometimes think about though: The fact it has clickable links and complex formatting rules for markdown, the most interactive and highest-quality clickable interface I've ever seen in a terminal, and somehow manages to work. That actually blows my mind. THEN, I'm reminded…

You’ve been writing code for 24 years and you don’t know that clickable links are a terminal emulator feature and not a Claude Code feature? Or that “markdown formatting” is just ansi escape codes, and possible with things other than React that don’t bring so many downsides?

Correctly emitting the right escape codes at the right positions is arguably very much a Claude Code "feature", as it is on CC to do so.

Re: Claude Code uses Bun written in Rust now

#757

Post by jstimpfle »

Conscat wrote: post #743
jstimpfle wrote: post #683

Earlier quoted context omitted.

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++.

Fair enough, this is an extension though and I suppose you could use it with manually constructed vtables as well?

Re: Claude Code uses Bun written in Rust now

#758

Post by abc42 »

frollogaston wrote: post #531
abc42 wrote: post #506

Earlier quoted context omitted.

>If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper. Yeah, good question. OpenAI decided to rewrite Codex in Rust about a year ago[0]. In fact, since rewrites are that easy, what do we need Bun for? Why doesn't everybody just port all of their Javascript code into Rust? [0] https://github.com/openai/codex/discussions/1174

Code verbosity and complexity still matter with LLM coding

Yeah, they do, but probably not in quite the same way as it matters to humans.

Re: Claude Code uses Bun written in Rust now

#759

Post by firesteelrain »

LtWorf wrote: post #713
firesteelrain wrote: post #200

Earlier quoted context omitted.

I see what you are saying. My comment is rooted in the fact that different people are foregrounding different objections to Anthropic/Bun, and taken together it looks like whatever launches, someone will find a reason to be upset

Maybe you should consider the objections by their merit rather than just being angry someone dares to criticise anthropic?

Already did, a few comments up. Happy to go through specific objections again if useful. This particular comment was about thread-level dynamics, not a verdict on any one objection’s merit.

Re: Claude Code uses Bun written in Rust now

#760

Post by cromka »

vips7L wrote: post #426
cromka wrote: post #44

Earlier quoted context omitted.

I am getting into the frontend dev and one thing that I don't understand is why people use bun in the first place? It's not much better preforming, it's not much safer, it's still not 100% compliant. Some tests show it's actually slower than node. Why bother switching, then?

I don’t think you would use Bun for front end.

I mean, Astro on Bun?
Post reply on HN