> Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better

You get very few of the Rust guarantees when you litter your code with unsafe to get around the safety checks (which is what they're doing here). I would not recommend running this in production.

> Bun has had an extremely high amount of crashes/memory bugs

Any stats/source? Not that I think it's false

> and the ugly parts look uglier (unsafe) which encourages refactoring.

Looks like Bun owes that to itself to some extent, not solely because of the language

> Bun has had an extremely high amount of crashes/memory bugs due to them using Zig

This just sounds like they are not good at using Zig. I have been daily driving ghostty on linux for a fairly long time now and I have never seen these kinds of issues. I have also used ghostty on macos for a bit and didn't have any problems there either.

Zig is really good for writing stable and reliable code. There is also a database written in Zig that seems to be fairly successful [0].

I also wrote zig for some time and compiler/toolchain was really pleasant to use. I wrote more segfaults in Rust ffi code than all segfaults I had in Zig in total while I was writing Zig.

[0] https://tigerbeetle.com/

Last time i checked their issue tracker (in 2025), the main source of problem was the engine, not their Zig code. A lot of core dump was happening inside and around JSC.

And they're clearly marked as `unsafe`, so easy to find, which gives them a nice list of issues to address.

Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool? There is a lot of quality stuff made with C/C++, so what is Zig doing wrong?

Can you or someone shed some light on how much compute it took to do this?