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

621–630 of 920 posts

Re: Claude Code uses Bun written in Rust now

#621

Post by dnautics »

K0nserv wrote: post #399
skydhash wrote: post #293

Earlier quoted context omitted.

There are many things in life that are "fine" only when you take extreme care (knives, cars, industrial machinery,...). The thing is something like C has many usages and you can't just say "use Rust" and be done with it. Using Rust is not cost-free.

I'm not saying "never use C". The thing I dislike is the false dichotomy between "(Zig|C|Go) is simple unlike Rust, which is complex". A statement like that makes it sound like writing correct code in the former is easier when it's, in fact harder.

the thing is, as a pattern, footguns in zig are simple and easy to reason about (though they might be hard for an ADHD human to find). the compositional nature of rust sometimes makes footguns "hard to see" because they can be hidden behind layers of abstraction.

there is a potential future where an llm with unbounded patience would have an easy time literally walking through the zig code looking for one of the footguns might miss a footgun in rust because it's abstracted away. the ones in the stdlib should give you pause. what is hiding in some third party library's code?

Re: Claude Code uses Bun written in Rust now

#622

Post by nestorD »

gchamonlive wrote: post #424
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…

> Rust does this automatically. It removes an entire class of errors from his backlog. Even with the huge amount of "unsafe" rust currently in bun? https://news.ycombinator.com/item?id=48967630

Fun fact, unsafe does not let you turn off the borrow checker in Rust: https://steveklabnik.com/writing/you-can-t-turn-off-the-borr...

Re: Claude Code uses Bun written in Rust now

#623

Post by MintPaw »

hugmynutus wrote: post #425
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 (…

This reads like cope because you're re-inventing RAII from first principles. I cannot take this seriously as tutorials on robust Zig Allocation Pools will store a deinit method for each item within the pool, so when the pool deinits, all internal objects can be deinit'd. That is just RAII & dtors from first principles, except with extra overhead of manually storing fat pointers yourself (and the bugs that come with t…

This is a general problem with destructors, you can't "batch delete" objects. To free a lot of stuff you're required to go pointer by pointer through the tree to clean up each object. To get real performance gains from pools you can't have per-object/subobject custom cleanup code.

Re: Claude Code uses Bun written in Rust now

#624

Post by soulbadguy »

Diggsey wrote: post #613
BearOso wrote: post #401

Earlier quoted context omitted.

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

> 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

That's a semantic distinction which does not matter in the point OP is making. And contrasting rust static approach to general GC.

Re: Claude Code uses Bun written in Rust now

#627

Post by thewhitetulip »

aurareturn wrote: post #609
thewhitetulip wrote: post #599

Earlier quoted context omitted.

Why is ecosystem of tools and plugins a bottle neck when they literally own Claude models and as per their boss, code is so cheap that anything us just an English sentence away?

I knew this was going to be the first reply. The answer is because you still need at least one human to develop and test any tool, integration, feature.

Why? Use agent bruh. Even the bun rewrite post said that agents do writing testing everything!!!

Unless AI overlords lied and we do need humans

Re: Claude Code uses Bun written in Rust now

#628

Post by lmm »

weakfish wrote: post #212

Maybe I’m taking crazy pills, but I’m still stuck on “why the hell does a TUI need to run in terminal React by way of JavaScript” The fact that Anthropic felt the need to buy a runtime so they could make their TUI better speaks more to the quality of engineering than anything else IMO. If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.

> why the hell does a TUI need to run in terminal React by way of JavaScript

Because React is the only UI framework that takes the problem seriously. Everything else is stuck in the dark ages.

How HN gets this so badly backwards I'll never understand. Everyone on this site talks a big game about "there shouldn't be so many competing tech stacks, why can't everyone work together on one framework that does things right", and then as soon as that framework actually appears this site hates it more than anything.

Re: Claude Code uses Bun written in Rust now

#629

Post by windexh8er »

theshrike79 wrote: post #471
gchamonlive wrote: post #424

Earlier quoted context omitted.

> Rust does this automatically. It removes an entire class of errors from his backlog. Even with the huge amount of "unsafe" rust currently in bun? https://news.ycombinator.com/item?id=48967630

You think it’ll all stay there? Of course they’ll iterate and remove the unsafe bits which were necessary for the transition

Except the transition was never necessary. Yet another Anthropic marketing effort so they could claim a shallow victory [0].

[0] https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...

Re: Claude Code uses Bun written in Rust now

#630

Post by 512colors »

you know what i hate? i hate that each update, to codex or claude code, it seems like they're always trying to "hide stuff" , reminds me of the 80s and 90s when tech assumes normal people are too stupid to see 'raw' stuff like terminal commands being run, its always been like that, less so now, but i get so mad when its doing stuff, and i can't see if its deleting files or just screwing something up. btw this is totally free tool buttonscli.com that is a full UI terminal app but its got a button for agent control. You click that, paste into claude code or w/e/any agent, and it'll use that for the terminal commands instead of the built in one so you can see everything (and it can open 10 tabs if it wants, you see them all)
Post reply on HN