Claude Code uses Bun written in Rust now

Post by kllrnohj » Mon, Jul 20, 2026, 11:30 AM UTC

jstimpfle wrote: post #683

kllrnohj wrote: post #617

Earlier quoted context omitted.

Re #3: vtable pointers aren't mutable...?

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

Post by hresvelgr » Mon, Jul 20, 2026, 11:35 AM UTC

rob74 wrote: post #724

hresvelgr wrote: post #722

Earlier quoted context omitted.

> You can just do that, and then Zig is really no less robust than Rust. That's just it, using Zig required more rigorous engineering than the Bun team were capable of.

People tried to "just do that" (write their programs in a memory safe way) in C and other languages with manual memory management for decades, and we have countless vulnerabilities that prove this simply doesn't work. That's why newer languages, with the notable exception of Zig, prefer more advanced memory management methods.

Post by dwattttt » Mon, Jul 20, 2026, 11:37 AM UTC

NohatCoder wrote: post #733

dwattttt wrote: post #619

Earlier quoted context omitted.

Relative "number of unsafe keywords" or "lines inside unsafe blocks" isn't a good metric. It's unsafe to call a C library that gives you a raw pointer, that can be a single line. It's unsafe to use that pointer, that could be a second single line. Carrying that pointer around, the data structures it's in, that's all safe, and doesn't implicate lifetime checking at all, so Rust will let you do silly things with the ac…

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.

Post by adwn » Mon, Jul 20, 2026, 11:38 AM UTC

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…

    fn oof(x: &u32) -> &'desired u32 {
        let ptr = x as *const u32;
        unsafe { &*ptr }
    }

    fn main() {
        let mut x = 1_u32;
        let reference_a = &mut x;
        let reference_b = trust_me_bro(reference_a);
        *reference_b = 2;  -- Whoops
        println!("reference_a: {reference_a}  reference_b: {reference_b}");
    }

Post by aureate » Mon, Jul 20, 2026, 11:42 AM UTC

zahlman wrote: post #674

aureate wrote: post #67

The port of Bun, which has >5000 open github issues, is used in Claude Code, which has >11000 open github issues. Do people use Bun in things that are expected to work reliably? Have any such projects tried the upgrade yet?

To be fair, https://github.com/python/cpython has over 5k open github issues, and that's still generally considered fairly reliably technology even if a lot of HN users seem to hate it.