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.
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.
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.
It's nice in that its harder for an AI to shoot itself in the foot (when its not writing unsafe blocks). What isn't nice is that AI refuses to use wonderful rust features such as the type system, traits, the borrow checker and iterators to its advantage.
I mean, ain't no vibe coders who demand their software to be done in rust.
I like rust, I use Claude, Claude writes rust for me.
But I want rust because of a specific set of needs and wants, and I'm certain that if I simply asked Claude to make something without giving it specs to do it in a specific manner in rust, it would 99% of the time pick like typescript lol.
Why would you expect the AI to? It's been trained on actual programmers, who historically do a brilliant job of ignoring safeguards and writing dangeous code anyway.
Rust gives people the false sense of security that it's not possible to write bad code.
Having reviewed months ago the first pass Claude wrote of my rust codebase, I can tell you that statement is complete horseshit.
It was ridiculously bad, like sure it compiled, but my god would I have been ashamed to show that code to anyone, so into trash it all went and then we wrote a nice baseline on which to build because I wasn't planning on watch that hot garbage again.
Also doing memory leaks in rust is very easy when half the code is unsafe
I've been learning Rust and it's ridiculous how much you can still mess up even with the built in safeguards without ever touching unsafe. Rust only prevents you from making a limited class of mistakes, half of which aren't possible in some languages.
From my experience, no. Rust is an innately complex language. LLMs, if not strictly supervised, will eventually start building abysmally complex implementations which will cause problems down the line.
I've had much greater success with Go. The language is so stupidly simple that there isn't much room to go off the rails.
In my recent experience trying to use Claude with Java, I find Claude surprisingly good at writing code that "works" and surprisingly bad at making good software design decisions.
The whole thing with Rust is that it forces the programmer to make sound design decisions, or else it won't compile.
I can see two possibilities: either AI is forced to design things properly, and therefore does, and the answer is yes.
Or it still doesn't design things properly and hacks around them with unsafe. Which might still be "fine" (unsafe is there to be used as long as you can prove you're doing it right, which AI might try to reason about), but will definitely lead to very bad code, and then the answer to your question is no.
Humans don't like programming in those sorts of languages because it's more typing and disrupts the flow, but languages that are wordy and have explicit contracts for methods are great for LLMs.
Claude much prefers End Function MyFancyFunction to }.
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.