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

711–720 of 920 posts

Re: Claude Code uses Bun written in Rust now

#711

Post by LtWorf »

CrimsonRain wrote: post #169
_pdp_ wrote: post #10

Earlier quoted context omitted.

I am impartial on the matter, but I think one of the reasons Bun became a thing in the first place was because of Zig attracted a small but very active developer community. Switching from Zig to Rust effectively alienates that community.

Bun became a thing because it provided some specific benefit to js ecosystem. Zig enabled the rapid development. The people who contributed were definitely helpful but they can still choose to help or not and new people will step up too

> new people will step up too

Or they will not… how could you possibly know.

Re: Claude Code uses Bun written in Rust now

#712

Post by zombot »

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…

What's the point of using Rust in the first place when you disable the compiler feature that protects you the most?

Re: Claude Code uses Bun written in Rust now

#713

Post by LtWorf »

firesteelrain wrote: post #200
embedding-shape wrote: post #196

Earlier quoted context omitted.

My overall larger point (maybe poorly stated) was that unless you're engaged specifically in a 1-on-1 conversation with someone, accusing a whole community of "moving the goalpost" makes no sense, there is a whole host of arguments and points being made in different directions all the time, by different individuals.

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?

Re: Claude Code uses Bun written in Rust now

#714

Post by zombot »

Ygg2 wrote: post #654
gcr wrote: post #616

Earlier quoted context omitted.

It’s my understanding that bun was ported to unsafe rust, so even these gains would require additional effort on the team’s part, right?

Unsafe Rust doesn't automagically disable typesystem (& borrow checker, but lifetime are a sort of types). Once raw pointer is turned into a T, &T or &mut T, the borrow checker is on.

Borrow-checking the dereference of a stale pointer won't be worth much, though.

Re: Claude Code uses Bun written in Rust now

#715

Post by LtWorf »

realo wrote: post #152
flohofwoe wrote: post #38

Earlier quoted context omitted.

An interesting tidbit is that large parts of the original Bun source code was a line-by-line port of esbuild from Go to Zig (mentioned here: https://bun.com/blog/bun-in-rust ), tbh this lowered my respect for the project a bit (a line-by-line port simply isn't as interesting as original work), and it might also explain the subpar Zig code quality (a line-by-line port from Go to Zig simply won't result in idiomatic Zi…

I read your link, written by Bun's author and totally get his thinking. In the current world of cyber weaknesses everywhere, infrastructure must be solid and rust is a better choice than zig for something like bun. In other words, bun is not a demo of zig programming that happens to do useful things. Bun does useful things, and must do them securely. That is its number one priority, language is secondary, inasmuch as…

I don't think you can claim your code is secure, or can claim anything at all about your code, if you haven't written the code and have no idea what's in there.

Rust protects against a rather small group of memory error, if and only if the unsafe sections are actually correct. And nobody knows if they are correct or not, plus there can be millions of logical errors that can be exploited.

See how many CVEs uutils has… quite a lot for a supposedly secure rewrite of GNU coreutils.

Re: Claude Code uses Bun written in Rust now

#716

Post by aurareturn »

thewhitetulip wrote: post #680
aurareturn wrote: post #675

Earlier quoted context omitted.

Show me where Anthropic claims you don't need any humans anymore to build working, production ready software.

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

News flash: most of software engineering is already automated. When was the last time you wrote code?

They did not claim there is no human involved.

Re: Claude Code uses Bun written in Rust now

#717

Post by lionkor »

harrisi wrote: post #483

Maybe I'm taking crazy pills, but I swore there have been very similar comments I've seen as the current top post by weakfish: > 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. >…

It's because rewrites are almost always a bad decision. Best case, it's a naive decision made by people who don't know better, worst case it kills the product (who here uses netscape?).

So, from the start, people will be skeptical of a "we rewrote xyz in Rust" because it rarely works out. But there's a lot more to this, in fact it's a little bit loaded with "tech bro" ideas:

- Rewriting in Rust

- Rewriting using AI

- Making terminal apps in JS

- Zig (a lot of people's dear language) is involved somehow

This attracts every single skeptical developer. The only thing missing is maybe blockchain, if that was still cool. It just hits all the "what? why?" spots.

I was already writing a comment, when I realized that what I wanted to write had already been said by the top comment. I suppose that's why comments read so similarly.

Re: Claude Code uses Bun written in Rust now

#718

Post by LtWorf »

switz wrote: post #236
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.

It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question. They chose it early on, it works, and it makes obscene amounts of revenue. End of story. That doesn't mean it was the "greatest" choice, or has a perfect technical architecture. Rewrites are never easy, even the bun rewrite. But a non-UI developer tool with a rig…

For a company that solved coding and doesn't need any software engineers… why spend money to acquire a runtime rather than ask claude to rewrite it in assembly directly and be done with it?

Could it be that they aren't being entirely honest?

Re: Claude Code uses Bun written in Rust now

#719

Post by lionkor »

scrollaway wrote: post #587
slopinthebag wrote: post #576

Earlier quoted context omitted.

Formatted hyperlinks are an escape code too. It has nothing to do with React. Not sure why you’re trying to bring up experience as a justification for using React to render a tui and all the downsides that come with that.

It sounds like you completely missed the point I was making: that actually implementing such a highly dynamic TUI application normally requires a significant amount of state tracking and it is significantly easier to write such apps using a functional, descriptive UI framework instead of something like ncurses. Take it from someone who, in those 24 years, has written UIs in jquery, react and ncurses (and yeah I've tr…

There are fantastic TUI frameworks for Rust, like Ratatui[0] (there are a lot more options, this is an example). You can write beautiful TUIs in native languages, without ncurses or C or C++.

Go has such frameworks, same with C# (which you can AOT compile) and so on. You're not stuck between javascript and C.

[0]: https://ratatui.rs/

Re: Claude Code uses Bun written in Rust now

#720

Post by z0ltan »

physicsguy wrote: post #704
WD-42 wrote: post #663

Earlier quoted context omitted.

All necessary memory is allocated at initialization. The application is not allowed any allocations during it's normal runtime. This is how it avoid memory bugs. Not a lot of people write programs this way.

Static memory allocation is widely used in quite a bit of embedded software, particularly safety critical stuff. There it's often latency related since you don't want hangs while memory is allocated. I've even seen it on some simulation software's core that was written in the 80s originally; at the time memory was much more constrained so allocating upfront meant you could check upfront whether the simulation could a…

[dead]
Post reply on HN