Remix.run Logo
jmull 17 hours ago

Rust doesn't prevent programs from having logic errors.

If LLMs produce code riddled with bugs in one language it will do in other languages as well. Rust isn't going to save you.

lmm 11 hours ago | parent | next [-]

Idiomatic Rust prevents many classes of logic errors. Just having proper sum types eliminates many (perhaps most) common logic errors.

loeg 17 hours ago | parent | prev | next [-]

> Rust doesn't prevent programs from having logic errors.

Like everything around Rust, this has been discussed ad nauseam.

Preventing memory safety bugs has a meaningful impact in reducing CVEs, even if it has no impact on logic bugs. (Which: I think you could argue the flexible and expressive type system helps with. But for the sake of this argument, let's say it provides no benefits.)

zdragnar 17 hours ago | parent [-]

It isn't like rust is the only language with memory safety; plenty of high level languages don't let you fiddle with memory bits in a way that would be unsafe. The tradeoff is that they typically come with garbage collectors.

If the only concern is "can an LLM write code in this language without memory errors" then there's plenty of reasons to choose a language other than Rust.

nialv7 17 hours ago | parent | next [-]

But the author isn't saying we should program in any of these memory safe languages. The author is saying why don't we vibe code in C, or even assembly.

zdragnar 16 hours ago | parent [-]

This thread moved the conversation away from the posted article quite a few messages ago.

First, Rust has lots of checks that C and assembly don't, and AI benefits from those checks. Then, a post about those checks are related to memory safety, not logic errors. Then, a post about whether that's a helpful comment. Finally, me pointing out that checks regarding types and memory errors aren't unique to Rust and there's tons of languages that could benefit.

Since you want to bring it back to the original article, here's a quote from the author:

    Is C the ideal language for vibe coding? I think I could mount an argument for why it is not, but surely Rust is even less ideal. To say nothing of Haskell, or OCaml, or even Python. All of these languages, after all, are for people to read, and only incidentally for machines to execute. 
It would seem that the author fundamentally misunderstand significant reasons for many of the languages he mentions to be the way that they are.
9rx 15 hours ago | parent [-]

> Rust has lots of checks that C and assembly don't, and AI benefits from those checks.

Fil-C gets you close in the case of C, but we can ignore it because, of course, F* has significantly more checks than Rust, and AI benefits from those checks. Choosing Rust would be as ridiculous as choosing C if that was your motivation.

But if you don't find the need for those checks in order to consider Rust, why not C or even assembly instead?

nylonstrung 7 hours ago | parent [-]

Fil-C is way too new for LLMs to understand it and not just hallucinate back into normal C

Maxatar 15 hours ago | parent | prev [-]

The trade-off is intended to make it easier for people to write software. Garbage collected languages make it easier for people to write memory safe code at the expense of performance, significantly greater memory usage, and heavy dependencies/runtimes.

These trade-offs are wholly unnecessary if the LLM writes the software in Rust, assuming that in principle the LLM is able to do so.

socalgal2 12 hours ago | parent | prev | next [-]

technically true but so what?

https://security.googleblog.com/2025/11/rust-in-android-move...

That team claims that not having to deal with memory bugs saved them time. That time can be spent on other things (like fixing logic errors)

j16sdiz 8 hours ago | parent [-]

That time can be spent on solving rust type puzzles

DonHopkins 15 hours ago | parent | prev | next [-]

All kinds of drugs produce unwanted risks and side effects if abused, so let's abuse crystal meth! Cannabis isn't going to save you.

IshKebab 15 hours ago | parent | prev | next [-]

> Rust doesn't prevent programs from having logic errors.

Nobody ever claimed that. The claims are:

1. Rust drastically reduces the chance of memory errors. (Or eliminates them if you avoid unsafe code.)

2. Rust reduces the chance of other logic errors.

Rust doesn't have to eliminate logic errors to be a better choice than C or assembly. Significantly reducing their likelihood is enough.

ux266478 12 hours ago | parent [-]

Can these claims back themselves up with a study showing that over a large population size with sufficient variety, sourced from a collection of diverse environments, LLM output across a period of time is more reliably correct and without issue when outputting Rust? Otherwise this is nothing but unempirical conjecture.

IshKebab 12 hours ago | parent [-]

Ah the classic "show me ironclad evidence of this impossible-to-prove-but-quite-clear thing or else you must be wrong!"

Although we did recently get pretty good evidence of those claims for humans and it would be very surprising if the situation were completely reversed for LLMs (i.e. humans write Rust more reliably but LLMs write C more reliably).

https://security.googleblog.com/2025/11/rust-in-android-move...

I'm not aware of any studies pointing in the opposite direction.

ux266478 6 hours ago | parent [-]

Actually it's the classic "inductive reasoning has to meet a set of strict criteria to be sound." Criteria which this does not meet. Extrapolation from a sample size of one? In a context without any LLM involvement? That's not sound, the conclusion does not follow. The point being, why bother making a statistical generalization? Rust's safety is formally known, deduction over concrete postulates was appropriate.

> it would be very surprising if the situation were completely reversed for LLMs

Lifetimes must be well-defined in safe Rust, which requires a deep degree of formal reasoning. The kind of complex problem analysis where it is known that LLMs produce worse results in than humans. Specifically in the context of security vulnerabilities, LLMs produce marginally less but significantly more severe issues in memory safe languages[1]. Still though, we might say LLMs will produce safer code with safe Rust, on the basis that 100,000 vibe coded lines will probably never compile.

[1] - https://arxiv.org/html/2501.16857v1

IshKebab 3 hours ago | parent [-]

I never claimed to be doing a formal proof. If someone said "traffic was bad this morning" would you say "have you done a scientific study on the average journey times across the year and for different locations to know that it was actually bad"?

> LLMs produce worse results in than humans

We aren't talking about whether LLMs are better than humans.

Also we're obviously talking about Rust code that compiles. Code that doesn't compile is 100% secure!

unethical_ban 16 hours ago | parent | prev | next [-]

This is objectively wrong.

You can't get a gutter ball if you put up the rails in a bowling lane. Rust's memory safety is the rails here.

You might get different "bad code" from AI, but if it can self-validate that some code it spits out has memory management issues at compile time, it helps the development. Same as with a human.

wizzwizz4 15 hours ago | parent [-]

> You can't get a gutter ball if you put up the rails in a bowling lane.

Sure you can. It's difficult, and takes skill, but it can be done.

sophacles 16 hours ago | parent | prev | next [-]

Modern medicine can't prevent or cure all diseases, so you might as well go back to drinking mercury then rubbing dog shit into your wounds.

Modern sewers sometimes back up, so might as well just releive yourself in a bucket and dump it into your sidewalk.

Modern food preservation doesn't prevent all spoilage so you might as well just go back to hoping that meat hasn't been sitting in the sun for too many days.

staticassertion 17 hours ago | parent | prev [-]

> Rust doesn't prevent programs from having logic errors.

Sure, but it prevents memory safety issues, which C doesn't. As for logic bugs, what does prevent them? That's a bigger question but I'd suggest it's:

1. The ability to model your problem in a way that can be "checked". This is usually done via type systems, and Rust has an arguably good type system for this.

2. Tests that allow you to model your problem in terms of assertions. Rust has decent testing tooling but it's not amazing, and I think this is actually a strike against Rust to a degree. That said, proptest, fuzzing, debug assertions, etc, are all present and available for Rust developers.

There are other options like using external modeling tools like TLA+ but those are decoupled from your language, all you can ever do is prove that your algorithm as specified is correct, not the code you wrote - type systems are a better tool to some degree in that way.

I think that if you were to ask an LLM to write very correct code then give two languages, one with a powerful, express type system and testing utilities, and one without those, then the LLM would be far more likely to produce buggy code in the system without those features.

skydhash 16 hours ago | parent [-]

Logic errors always stems from lack of understanding and inattention. The former is resolved by good communication and analytical skills. The other is just human nature, but we do have guardrails to help, like static analysis and tests. If used correctly.

There are static tools available for C as well. What you get from Rust mostly is that the check is part of the syntax of the language as well and escaping from it is very visible. You get safety, but you give up flexibility and speed.