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

881–890 of 920 posts

Re: Claude Code uses Bun written in Rust now

#881

Post by jdiff »

CrimsonRain wrote: post #880
jdiff wrote: post #870

Earlier quoted context omitted.

No, that's not correct. That is the discussion started by the article, and the one continued in many other comment threads, even including this one far further upthread. Conversations drift over time, and this thread has evolved into a subdiscussion on the topic of the rewrite itself. If this is not what you would like to discuss, I suggest you visit the other threads. If you would like to join us in this thread now…

Bun "contributor community", that provides significant amount of code contribution, is largely non-existent. Almost all of the work is done by Jarred and others at Oven. If someone still wants to contribute, they can do so on Rust. There is no reason to give warnings and plenty of time just to delay something like this when doing it rapidly is possible (now with AI). Bun "user community", is not affected by this at a…

This statement of a lack of community is at odds with the plentiful pull requests that were open before the rewrite.

This is, as you say, unprecedented. Not impossible, cautious optimism is a fine response. But to bring back a point I made earlier in the new old light: Then let's be cautious. Let's do some announcements ahead of time. Let's get some people in and get some physical hands on the codebase. Let's not go from "Stop freaking out, it's just an experiment!" to a silent merge to main in a week. That causes reduced trust in the project from those even just a hair less optimistic than you, and that's clearly unhealthy for the project no matter how you define "the community."

Re: Claude Code uses Bun written in Rust now

#882

Post by CrimsonRain »

jdiff wrote: post #881
CrimsonRain wrote: post #880

Earlier quoted context omitted.

Bun "contributor community", that provides significant amount of code contribution, is largely non-existent. Almost all of the work is done by Jarred and others at Oven. If someone still wants to contribute, they can do so on Rust. There is no reason to give warnings and plenty of time just to delay something like this when doing it rapidly is possible (now with AI). Bun "user community", is not affected by this at a…

This statement of a lack of community is at odds with the plentiful pull requests that were open before the rewrite. This is, as you say, unprecedented. Not impossible, cautious optimism is a fine response. But to bring back a point I made earlier in the new old light: Then let's be cautious. Let's do some announcements ahead of time. Let's get some people in and get some physical hands on the codebase. Let's not go…

If an experiment goes wildly successful beyond imagination, rapid pivot is only natural.

Jarred earned the trust by providing value. People who say trust is reduced without actually seeing the result, never had trust to begin with.

It's not like they merged and dumped it on to the world immediately. It's available as canary. They are doing their own dog fooding. Prisma is using the canary successfully.

As long as oven team can deliver a zig version equivalent stable bun, it is a success in my book. After that they can focus on resolving as many unsafe as possible and then the real benefits will materialize.

Re: Claude Code uses Bun written in Rust now

#883

Post by frio »

yathaid wrote: post #706
frio wrote: post #689

Earlier quoted context omitted.

I think what folks want, but aren't quite able to articulate, is an ongoing community and effort that indicate a project will be healthy and maintained. We want to be able to rely upon the software that we are choosing to use. Regardless of the technical choices, whether Rust is better or worse, whatever -- pgrust popped into existence thanks to one person driving an LLM through 7000 commits in ~2 weeks. It produced…

I am not saying anything about the viability of that particular project; just that one argument that was repeatedly made in that thread which I think is frankly nuts.

Yeah. I guess what I'm saying is that I feel like we're all still stuck debating these things on technical merits alone. The `bun` rewrite and `pgrust` both expose something -- I find, at least! -- uncomfortable about how we understand the technical side of our profession, but I think the social side remains the same.

Re: Claude Code uses Bun written in Rust now

#884

Post by KingMob »

Yokohiii wrote: post #659
KingMob wrote: post #656

Earlier quoted context omitted.

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.

Can you elaborate on the unusual part?

A number of commenters have pointed out static allocation, but none mentioned TigerBeetle's sophisticated testing suite, which is more relevant.

See here for a post on their deterministic simulation harness: https://tigerbeetle.com/blog/2023-07-06-simulation-testing-f...

Re: Claude Code uses Bun written in Rust now

#885

Post by zombot »

dkersten wrote: post #847
zombot wrote: post #712

Earlier quoted context omitted.

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

Because it lets you constrain the parts that the compiler can’t check and has to trust you on. The alternative is either a langue that can’t do necessary things, or a language that can’t check what could be checked. With unsafe, you’re telling the compiler “I’ve taken extra care to make sure that what I’m doing is safe and doesn’t break your rules” and the compiler can go ahead and assume that you don’t, in fact, bre…

Yes, when a human does it. With an LLM, the "trust me, I took extra care" is extremely doubtful. If LLMs could do that, they might as well use unsafe languages.

Re: Claude Code uses Bun written in Rust now

#886

Post by cush »

pier25 wrote: post #860
cush wrote: post #848

Earlier quoted context omitted.

I meant continuing to develop it

why would anybody invest all that time to understand and maintain a mess (according to the creator of zig) of 500k lines of zig code?

Because they’re complaining about it moving to Rust. I don’t know. I’m just saying, they can do something about it instead of complain

Re: Claude Code uses Bun written in Rust now

#887

Post by DSMan195276 »

josephg wrote: post #877
DSMan195276 wrote: post #846

Earlier quoted context omitted.

> But the bug is still almost always in an unsafe block. That's entirely dependent on how you write your Rust code. If you're derefing an invalid pointer then the bug is usually in how you calculated that pointer value, but the only part that actually requires 'unsafe' is the deref, not the bugged pointer calculation. Now in properly written Rust code you should be marking all of that code as 'unsafe' in that case an…

> The only part the compiler actually enforces is that you mark the specific spots where you make use of the operations that 'unsafe' allows. Yes, I wish there was a way to mark code as unsafe without also allowing unsafe operations. Its quite common I have some "safe" code that generates values which are eventually used in an unsafe block. If the "safe" code is wrong, my unsafe code will fail in memory-unsafe ways.…

Yeah I agree with that as well, the unsafe keyword takes on a double-duty which makes it unclear how it's actually intended to be used. The idea that you might mark a function that's only made of safe code as 'unsafe' is not that obvious and not always agreed upon, I've seen plenty of debating about it.

The fact that 'unsafe' also enables all unsafe operations in the function body just makes it even messier, since you definitely _don't_ want that unless the entire body is really nothing but unsafe operations. Thus the "mark a safe function as unsafe" has a clear downside since it allows all the unsafe operations you didn't want to use.

Re: Claude Code uses Bun written in Rust now

#888

Post by dwattttt »

DSMan195276 wrote: post #887
josephg wrote: post #877

Earlier quoted context omitted.

> The only part the compiler actually enforces is that you mark the specific spots where you make use of the operations that 'unsafe' allows. Yes, I wish there was a way to mark code as unsafe without also allowing unsafe operations. Its quite common I have some "safe" code that generates values which are eventually used in an unsafe block. If the "safe" code is wrong, my unsafe code will fail in memory-unsafe ways.…

Yeah I agree with that as well, the unsafe keyword takes on a double-duty which makes it unclear how it's actually intended to be used. The idea that you might mark a function that's only made of safe code as 'unsafe' is not that obvious and not always agreed upon, I've seen plenty of debating about it. The fact that 'unsafe' also enables all unsafe operations in the function body just makes it even messier, since yo…

> The fact that 'unsafe' also enables all unsafe operations in the function body just makes it even messier

This changed in the 2024 edition to now fire a warning lint, asking you to wrap your unsafe operations in an unsafe block, even inside an unsafe function.

Re: Claude Code uses Bun written in Rust now

#889

Post by munksbeer »

weakfish wrote: post #320
coldtea wrote: post #295

Earlier quoted context omitted.

> 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. Your counter argument would be valid for a 2000 or a 2020 business decision about some tech stack. But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build w…

Yeah, this is what I’m trying to get at. There’s two arguments in competition: 1. LLMs make it cheap (in the time sense) and easy to build 2. Rewrites and/or writing something in a native app or program is harder and more time consuming I think I am willing to take it as an axiom that a native version of CC would be superior from a user perspective. Performance, etc. I just don’t see how one can say that building thi…

> I just don’t see how one can say that building things reliably good is easy now when the company providing these tools can’t even do it well.

What do you mean? Claude cli is wildly successful. Why do they need to re-write?

Post reply on HN