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

841–850 of 920 posts

Re: Claude Code uses Bun written in Rust now

#841

Post by adwn »

Ygg2 wrote: post #810
adwn wrote: post #777

Earlier quoted context omitted.

> The only thing unsafe does is let you have an unbounded lifetime. No, you're wrong: You can create any lifetime. Proof: fn oof (x: &u32) -> &'desired u32 { let ptr = x as *const u32; unsafe { &*ptr } } This will take a reference and return it with any lifetime specified by the caller. > You don't disable anything. I said " effectively disable". For example: fn trust_me_bro (x: mut u32) -> &'a mut u32 { unsafe { &mu…

> Proof: You just listed examples of unbounded lifetimes. > I said "effectively disable". For example: Not sure what you meant by this example since it doesn't compile. It seems the borrow checker caught your mischief. So much for effectively disabling stuff :P You haven't effectively disabled anything; you just (tried to) wrote unsound code that washes one mutable ref as another. This stuff is allowed provided share…

> You just listed examples of unbounded lifetimes.

You're just splitting hairs and trying to weasel around the fact that yes, you really can create any lifetime you want using unsafe.

> Not sure what you meant by this example since it doesn't compile.

That's because the crappy HN formatting ate some of the characters. Here's the original version:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

> What you probably meant is […]

If you know what I meant, then what's up with your snarky comment about "So much for effectively disabling stuff"? In your playground link, you did effectively disable the borrow checker in safe parts of the code. Next thing you're moving the goalpost, now it's not about external, static analysis tools: "run this with UBSAN, ASAN, and other C tools". I don't think you're arguing in good faith here. Goodbye.

Re: Claude Code uses Bun written in Rust now

#842

Post by queenkjuul »

atonse wrote: post #18
junon wrote: post #5

Earlier quoted context omitted.

Why does changing to Rust kill the project? I don't understand the point here.

It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge. I feel weird having to defend reality; reality being that it was merged nearly 2 months ago and tons of people have had their pitchforks out without a shred of actual evidence that this made bun worse in any measurable way. But they still insist it was a mistake. I’ve never met Jared or the bun team but I…

>It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.

The rust code is not yet in a stable release, and CC only switched to it in the latest version, so there's not been 60 days of widespread battle testing yet, so i don't see how we could possibly say it will have no negative difference. It hasn't, because nobody is using it yet. It still might.

>Literally who cares what language a JS toolset is written in?

I don't care what language it's in, but i do care how it is written and maintained. I'm not going to trust my projects to a runtime that was written by an LLM in two weeks with practically no human review

Re: Claude Code uses Bun written in Rust now

#843

Post by adamrezich »

n6242 wrote: post #702
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.

I was just learning yesterday that's exactly what GTA did on PS2, which I thought was interesting. (Not to belittle your point, just giving an example)

This is how basically every console video game works.

Re: Claude Code uses Bun written in Rust now

#844

Post by jstimpfle »

kllrnohj wrote: post #771
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).

Then I don't understand your argument. If you're just saying what could go wrong with heap corruption, then your vtable complaint also applies to storing function pointers in arena allocators in Zig? Zig doesn't have anything special here?

I asked you what's wrong with pool destructor function pointers. You gave a reason what's wrong and I refuted it. So no, I'm not saying that storing a function pointer is special, just that nothing's wrong with it. (And implying that since there's nothing wrong and it's probably the most straightforward thing to do, it's also probably the right thing).

Re: Claude Code uses Bun written in Rust now

#845

Post by foldr »

simondotau wrote: post #819
NewsaHackO wrote: post #703

Earlier quoted context omitted.

Saying Bun's communication was an issue here is clutching pearls. There is no evidence that Bun ever acted in bad faith, Jared definitely seemed to initally think it was just a trial, until he realized that it was actually something feasible. He isn't clairvoyant; there is no way he would have known it was going to be successful when he initially made the post.

Bun isn't Bun, it's a (notionally) trillion dollar AI company famous for ruthlessness and engineering controversy for marketing purposes. Zig just happens to be a language led by someone with an AI-skeptic philosophy. Are you saying I should just believe that their strategically deniable negative insinuations about Zig are not bad faith? Sorry, but I'm calling bullshit. I know there's no absolute smoking gun here, bu…

The simplest explanation is that the Bun team decided to try rewriting Bun in Rust because they had some frustrations with Zig. I haven't seen any evidence that there's more to it than that. It's easy to get sucked into all the internet drama, but that only exists because Zig's author lost his cool and wrote a salty blog post, not because of any conniving on Athropic's part.

Re: Claude Code uses Bun written in Rust now

#846

Post by DSMan195276 »

josephg wrote: post #749
NohatCoder wrote: post #733

Earlier quoted context omitted.

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

> 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 and documenting what invariants need to be maintained, but that's entirely on you to do. The only part the compiler actually enforces is that you mark the specific spots where you make use of the operations that 'unsafe' allows.

Re: Claude Code uses Bun written in Rust now

#847

Post by dkersten »

zombot wrote: post #712
Ygg2 wrote: post #677

Earlier quoted context omitted.

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

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, break the rules, and therefore can verify everything else as if the rules never got broken.

In less safe languages, the entire program is “trust me, it’s safe”, while in rust only the parts flagged as unsafe are.

The point is that you should only use unsafe when 1. It’s absolutely necessary for functionality or performance and 2. You have verified and are very certain that the code is correct.

That’s a very useful property to have.

Re: Claude Code uses Bun written in Rust now

#849

Post by mexicocitinluez »

groundzeros2015 wrote: post #814
mexicocitinluez wrote: post #798

Earlier quoted context omitted.

This saying has been abused 10 ways til Sunday. "I'm using technology I know that will get us there" is not the same as treating every problem as a nail. It's making a practical choice that probably also had time constraints and other factors we don't know.

I think it’s completely applicable here. Nobody who worked in the 80s or 90s would have selected this solution.

> Nobody who worked in the 80s or 90s would have selected this solution

How does this support your argument? The tech didn't even exist in the 80s or 90s.

Saying "They wouldn't have made the same choices 40 years" is meaningless in this context. There's a lot of things they wouldn't have done back then that we do today. And this is a field that has been changing by the week recently, which makes even less appropriate.

This idiom now apparently means "I disagree with your tech choices" or in your case, "Someone 40 years ago would disagree with your tech choices".

Re: Claude Code uses Bun written in Rust now

#850

Post by queenkjuul »

entrope wrote: post #160
jeroenhd wrote: post #26

Earlier quoted context omitted.

My personal feelings about the matter is that having an LLM rewrite the entire thing as an experiment and then just going with it a few weeks later kills any incentive for a community to build up around it. It's a clear signal that every basic aspect of the runtime can change on a whim. I don't care about meh Zig being rewritten to bad Rust if it does the same thing, but taking what is presented as" look at this funn…

> taking that into production with barely any announcement is what kills off the interest to me. Did Bun v1.4.0 release weeks ago and I missed it? I would call a formal release the point that it goes "into production", and I think dogfooding it via Claude Code is yet another form of testing Bun-in-Rust before the latter goes to casual users.

Claude code isn't used by casual users?
Post reply on HN