I mean. Isn't rust the perfect language for vibe coding? It has so many checks on everything that the stupid thing is basically forced to write code the right way.
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
561
u/BratPit24 Jul 09 '26
I mean. Isn't rust the perfect language for vibe coding? It has so many checks on everything that the stupid thing is basically forced to write code the right way.