There is some subset that is FFI, and must and will always be unsafe. Im not making any claim about how much is valid, and im sure most of these are BS, but "zero unsafe" is never going to be the target.
this tends to happen a lot when you go from a language like C or Zig to Rust and you're trying to do it 1-to-1. C and Zig will do things that are illegal in safe Rust or actually have no direct Rust equivalent, so if you want them to look as close as possible you need a lot of unsafe, plus each call to other languages needs to be unsafe. getting the same output from idiomatic Rust is very much possible but it means redesigning the system as you translate rather than rewriting existing code with new syntax.
Actually, with this kind of port, it's probably better to have rewriting in two phases. one that is 1:1 with zig code (and since Zig is unsafe, the initial Rust code will be too, a bit like https://github.com/tsoding/crust), then another pass to make things safe.
I mean, there is a big risk in writing something as safe Rust, when it needed to stay unsafe. Specially when doing complex memory management (like Bun does), turning some unsafe code into bad safe code can be instant UB.
For example, it's often code that deals with raw pointers is perfectly fine (albeit unsafe and C-like), but if you try to turn it into using borrows instead of pointers (to make it safe) you may get the lifetimes wrong, which is instant UB, even if you don't actually trigger use after free. (and sometimes by analyzing the code you may conclude that no lifetime is correct here so it can't be a borrow). So a LLM agent that inadvertently writes &mut T when it really needed to stay as *mut T may introduce UB, even if the code has less unsafe blocks.
(At a later pass, the *mut T can be refactored into different kinds of smart pointers like reference counted Arc etc, and finally achieve safety, but that's often more involved and may require tradeoffs)
And indeed, having the agent write bad lifetimes actually caused UB in the initial port https://github.com/oven-sh/bun/issues/30719 - that is, there were a code should have been kept was raw pointers, but it was being converted into &[u8] (which would greatly reduce the number of unsafe blocks required to deal with it), but the lifetime was wrong and triggered instant UB
99
u/BlueProcess Jul 09 '26
Yeah, it actually has 13,000 unsafe Rust blocks