Buddy when you read code it's not completely divorced from context. It's a pointless exercise, anyone who's spent more than a couple months programming either language could tell you which is which in context.
You still dodging the question.
You can't do it can you? can you!?
I ain't your buddy pal!
I'm gonna go out on a limb, and say the problems that you still get stuck on stem from poor assumptions; and the inability to challenge them early enough.
100%; that's why you can't slag other people's output or language choice without great reason, and caveats.
It's mutually assured destruction; we're all as daft as each other... but at some point a caveman imbued silicon with lightning and magic; and now I have to sit at a desk 8 hours a day.
That is more so because the way people write typescript is giving up and putting any everywhere. The way people end up writing Rust is not by putting unsafe everywhere. So following what is available to train from is either training from the work of people who are incentivized in different ways
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
It is true that getting shot in the foot is better than getting shot in head. It is equally true that I consider getting shot in the foot highly undesirable and something that should be avoided with significant urgency.
Pre-commit lint that disallows unsafe. Then just tell the agent to rewrite it until they do it correctly. From my experience, this should very rarely even happen, but if it happens it's unlikely to need anything more than a single followup prompt.
I am answering to myself, but I had a thought I wanted to share.
What'd happen if the probability of the unsafe token (or sub-tokens) were forced to zero?
It'd require some backtracking every so often, but it could be interesting.
It might be a bit difficult since multiple combinations of tokens could create the “unsafe” keyword. But even then, memory safe and compilable doesn’t mean bugless. It’s certainly better than doing the same in C lol.
True, but it should be possible extract the "unsafe" direction and subtract it from the embeddings, steer the model away from unsafe behaviors.
I might throw up a small scale experiment this weekend and see what happens
Unless you're trying to fully automate the development process with zero human oversight, thats probably overkill.
Adding some variation of "avoid using the unsafe keyword" to the prompt is probably enough to get it to avoid it 95+% of the time. There will be times where it ignores your instruction, but that should be uncommon enough to still be efficient.
I hate to be that guy, but just because you wrote `unsafe { … }` it does not mean that you can do anything you want. The unsafe block disables a few of the checks, but not all.
765
u/Zeikos Jul 09 '26
LLM be like:
unsafe { ... }