Hacker News Reader

Just because something is written in Rust, doesn't mean it's good Rust.

I have noticed, in general, LLMs tend to "fix" problems by shoving them under the rug (like adding a cast) or writing a super-local "fix" instead of taking the time to understand the deeper problem or structure.

In Rust, when you get stuck in a complicated borrow-checking problem, Rust people will tell you it's a Good Thing(tm) because it forces you to think about the higher level architecture of your code. An LLM, on the other hand, might bash its head a couple of times trying to "fix" the problem, and then just throw in a Refcell (or other workaround), see that it compiles, and call it a day.

Refcells "move borrow checking to runtime", meaning that the code will compile, and will crash at runtime if the object is tried to be accessed from two different places at the same time. In most "normal" programming languages it's not an issue -- but it's a crash in Rust.

Now, maybe the models have gotten better, and maybe you can get around this problem by using a good system prompt/"tools" and a good testing methodology. What I am saying however is that you shouldn't automatically take "rewritten to Rust by AI" at face value of it being good Rust code, or a testimonial of "Rust and AI being a good match". (Go is better I think)

> Speaks volumes to the strengths of the language

Memory safety is just a tiny part of over all security. If a LLM can transcode correctly, then it should also output 100% correct C code.

On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.

> Memory safety is just a tiny part of over all security.

No, it's a pretty massive part with disproportionate severity.

> If a LLM can transcode correctly, then it should also output 100% correct C code.

Translating code seems to largely rely on having a strong suite of existing tests, not on ability to code correctly.

It's unclear if LLMs are great at writing safe C code, it's much clearer that they can meet targets with external feedback properties like "test passes/fails".

> On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.

This is very unclear to me.

> Memory safety is just a tiny part of over all security.

70%[1][2] is tiny?

[1]: https://www.zdnet.com/article/microsoft-70-percent-of-all-se... [2]: https://www.chromium.org/Home/chromium-security/memory-safet...

> On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.

Isn't it the other way around? Rust guarantees lack of undefined behavior in safe code. If you have undefined behavior in your code your bug might become a heisenbug, or make the rest of your program behave weird, or the bug might simply be dormant until a very specific situation occurs (i.e. be "soundless" as you say).

If you're going to automatically translate your code from one language to another then a memory-safe target language (whether it's Rust, Java, C# or something else) is the only sane, reasonable choice. And if you want C or C++-like performance (i.e. you want to maximize performance) then you're pretty much left with Rust on the table.

> If you have undefined behavior in your code your bug might become a heisenbug

OR, the OS might kick in and throw a segmentation fault etc, often with some information associated to it.

Again, if a LLM can output 100% correct code, no bug of whatever kind should exist. Seeing a segfault could just invalidate that assumption completely and definitively. That's the point.

> Rust guarantees lack of undefined behavior in safe code

And that don't guarantee heisenbug-free, that just means your heisenbug was fully checked by Rust compiler and is now managed by the language runtime/facilities.

So, now instead of a crashed program and a "sever" DoS vulnerably, you got a disconnected user every time they trigger the bug. The user might assume it's the network, so does your logging stack. After a few times, the user starts bitching about your stupid network, and left for your competitor's product, while you busily trying to figure out why the network suddenly ain't as good as it used to.

> 70%[1][2] is tiny?

It really depends on how they define what counts as "vulnerably", or in Chrome's case, "'high severity' security bugs" which is very specific. Microsoft probably have many decades-old code written before the invention of better checkers, that contributed to the problem.

> Memory safety is just a tiny part of over all security

Sure, in the same way that foundations are just a tiny part of house construction.

Foundations come first, it's great if you've got more on top, I recommend it actually, but if you don't have the foundations it's not even worth having the discussion about what else you built, it's all worthless.

But current LLMs have a context window limitation, so you can't fit your whole source code into the context, that's why compilers guide the LLMs when they are producing code and that's where Rust compiler shines, it has very good diagnostics that help fix the issues with a few iterations.

So while LLMs are good at writing walls of code, they do not produce good code, just good enough and sometimes it is wrong (here is where Rust can help a bit by checking that the program is sound, but for the most part you should also validate the logic).

The dream language for LLMs would be one that has some kind of proving that function inputs/outputs are what you expect (I think it's called proof theory, but it's not my area of expertise, so I could be wrong), you kind of can emulate this with new types[0].

[0] https://doc.rust-lang.org/rust-by-example/generics/new_types...

> If a LLM can transcode correctly, then it should also output 100% correct C code.

Well LLM's cannot transcode perfectly correctly, so the fact that Rust has lots of static checking is really important. Not just for memory safety - Rust helps with many other classes of bugs too.

> then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.

I think what you're saying here is that LLM's often cheat to solve the immediate error, e.g. by using `unsafe` where you really shouldn't, or just making a test not test anything. That's definitely possible.

> If a LLM can transcode correctly, then it should also output 100% correct C code

An LLM can't (currently) transcode correctly in a vacuum. It needs tight guardrails to keep it on the straight-and-narrow (such as an existing conformance test suite that is extremely comprehensive).

The value of transcoding to Rust specifically is that the compiler gives you a pretty substantial set of guardrails "for free" - in a C port, your conformance test suite would also need to test every aspect of memory safety and fearless concurrency...

> Speaks volumes to the strengths of the language, also speaks volumes that LLMs lift the barrier of entry for Rust programming, the borrow checker woes can be offloaded to the model, you focus on all the other programming logic.

I get the opposite impression. If they aren't confident enough to write it by hand, I think it means the language is either hard to write, hard to read, or both. And by delegating to a LLM, there's no "barrier of entry" being lifted, it's just saving you typing time (like it would if it was being translated to C or Kotlin). If they actually decide to "focus on all the other programming logic" and they aren't just vibe coding this, they'll still need to be able to understand and reason about the code.

> you focus on all the other programming logic

Does that actually happen?

For a model, yeah absolutely. You'll spend virtually 0 tokens on memory safety, which means your token budget gets allocated elsewhere. If you wrote a C codebase you'd need to allocate some portion of your budget towards memory safety.

They're not talking about the model, and they're not talking about token budgets.

This entire topic is about models, the grandparent post is about models augmenting human work, and my post is about models. I think it's fine.

Let's expand the actual quote we're responding to:

> the borrow checker woes can be offloaded to the model, you focus on all the other programming logic

Then the person you responded to asked if "you" really do "focus on all the other programming logic", given that "the model" deals with the borrow checker. In other words, they're asking about the work the actual human is doing at that point. You then replied talking about the model again and token budgets. In effect, you brushed the question under the rug and imply that _everything_ is offloaded to the model, no focus by the human required.

I think it's perfectly reasonable to provide an analog to substantiate an overall point.

> LLMs lift the barrier of entry for Rust programming

I think you actually meant "lower the barrier" (which would make it easier to pass the barrier, while lifting it makes it harder)?

This depends whether you have one of those barriers made of bollards that raise out of the ground (expensive, hard to retrofit on an existing parking structure), or the kind where an arm lowers across the road (cheap, trivial to retrofit)

I think such barriers are usually considered permanent and must always be overcome. You get over a barrier. So it is more like a wall or hurdle. In the metaphors of difficulty it is assumed there will always be some residual difficulty so there will still be a barrier, but one that is easier to get over, so it is replaced with a lower one.

Lift the barrier as in remove it completely

Not really, any Standard ML derived language would do.

Also I think this is all temporary, just like devs still did not believe on optimising compilers and checked each line of generated Assembly code, during the 1960's.

Eventually it will be natural language, and all languages will be kind of irrelevant.