Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

Post by staticassertion » Sun, May 10, 2026, 11:45 AM UTC

brabel wrote: post #528

josephg wrote: post #480

Earlier quoted context omitted.

> If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted. Yeah, I've heard of people being surprised that when they make massive collections of Box'ed entries, then get surprised that it takes a long time to Drop the whole thing. But this would be the same in C or Zig too. Malloc and free are really complex functions. Reducing heap allocations is an essent…

In zig the solution is to use an arena allocator. That’s about as easy as it gets. Maybe Rust also allows doing that, I don’t know.

Post by staticassertion » Sun, May 10, 2026, 11:52 AM UTC

__loam wrote: post #604

f311a wrote: post #548

Earlier quoted context omitted.

I think the main problem with Bun is that they are trying to move very quickly. Tigebeetle devs spend 90% time working on stability, safety, tests and so on. They don't need new features, they need reliable software. Their database is pretty simple in terms of features and their goal was always stability and speed. Bun devs spend the majority of the time adding new features.

Maybe they should put more consideration towards quality if they have a ton of memory issues.

Post by chrisco255 » Sun, May 10, 2026, 11:55 AM UTC

stingraycharles wrote: post #511

Chris2048 wrote: post #84

Earlier quoted context omitted.

It's been repeated many times that the rejection of the Bun PR was unrelated to their AI-policy. It's also not clear they've "fumbled the ball" given how many projects are complaining about slop PRs.

I think it would help if Zig put out a statement on their actual AI policy, regardless of whether they’d be repeating something that should already be known. As often happens, the online discourse has, for some reason, decided that this was an anti-AI stance, while - as far as I understand - the problem was simply that the PR had problems, which lead to Bun forking Zig.

Post by chrisco255 » Sun, May 10, 2026, 11:59 AM UTC

anttiharju wrote: post #562

Validark wrote: post #285

I'm a full time Zig developer, and I see this as an absolute win. I know Jarred has said in the past he feels Zig makes him more productive, but I also think it's fair to say Bun was programmed in a way that's quite cavalier towards buffer overruns. I think Jarred and the Oven team will have significantly better luck with Rust. Some commenters have remarked they only heard of Zig because of Bun, therefore this is bad…

I remember looking into the nodejs alternatives some years ago, one way to compare them is to look at the open issues. bun had so many hits for 'segfault' and deno has basically none. Even now: bun (zig) [1] 119 open / 885 closed deno (rust) [2] 0 open / 1 closed I don't think this has that much to do with Zig's anti-AI stance. More about using the right tool for the job. [1] https://github.com/oven-sh/bun/issues?q=i…

Post by kllrnohj » Sun, May 10, 2026, 12:06 PM UTC

__loam wrote: post #606

kllrnohj wrote: post #339

Earlier quoted context omitted.

Zig is a love letter to C. It does not do much of anything to address memory management. Doesn't even have any concept of ownership like C++ does (ergo, no equivalent of unique_ptr / shared_ptr). All you get over C is the addition of defer, and even that isn't really that different if you're using GCC or Clang and thus have __attribute__((cleanup)).

Zig does in fact do some stuff to address memory management like making allocations more explicit using allocators and shipping with arenas.