Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learnings from 100K lines of Rust with AI (2025)

zfhuang99.github.io

Post reply on HN
Print view View original

151–160 of 225 posts

Re: Learnings from 100K lines of Rust with AI (2025)

#151

Post by pjmlp »

rirze wrote: post #56
mike_hearn wrote: post #48

Earlier quoted context omitted.

It's not nearly the perfect language for LLMs and Rust is dramatically harder to read and reason about than Python with types. Other options work better for nearly all apps. I found Kotlin works well: - Garbage collected so no reasoning tokens or dev cycles are wasted on manual memory management. You say if you're vibe coding you can ignore lifetimes, but in response to a post that says AI can't do a good job and con…

Then your domain problem you’re trying to solve doesn’t benefit from Rust. Sounds like your work doesn’t need Rust and that’s ok. But don’t generalize.

Unless you're writing kernels, or high integrity systems with memory allocation constrains there is very little reason to use a language like Rust.

Everything that people find great on Rust with exception of the borrow checker, can be found in any compiled language from ML linage. And even that is fading away as they introduce a mix of linear types, dependent types, effects and formal logic.

Re: Learnings from 100K lines of Rust with AI (2025)

#152

Post by pjmlp »

boitiga wrote: post #30
jdw64 wrote: post #9

I'm also shifting to an vibe coding workflow, but I have a genuine question: whenever I use AI for Rust, it makes an insane amount of lifetime errors. I have no idea how people are churning out so many lines of code so quickly. Honestly, despite all the hype around Rust in the community, the fact that AI can't handle lifetimes reliably makes me reluctant to use it. The AI constantly defaults to spamming .clone() or w…

Honestly Rust is an UGLY language. For whatever powers it possesses in memory safety, its cryptic symbology is reminiscent of assembly. This is a problem when language designers are mathematicians and don’t understand typographical nuance and visual weights.

I would rather have people running for languages like D, but the automatic resource management stigma is high among certain classes of developers.

Re: Learnings from 100K lines of Rust with AI (2025)

#154

Post by pjmlp »

ramon156 wrote: post #25
jdw64 wrote: post #9

I'm also shifting to an vibe coding workflow, but I have a genuine question: whenever I use AI for Rust, it makes an insane amount of lifetime errors. I have no idea how people are churning out so many lines of code so quickly. Honestly, despite all the hype around Rust in the community, the fact that AI can't handle lifetimes reliably makes me reluctant to use it. The AI constantly defaults to spamming .clone() or w…

Clone is not "butchering idiomatic Rust", we gotta stop this nonsense

Well, some of us rather use languages with automatic resource management in the type system, in whatever form, and thus avoid typing .clone() all over the place.

Re: Learnings from 100K lines of Rust with AI (2025)

#155

Post by pjmlp »

kikimora wrote: post #59
ndr wrote: post #3

Earlier quoted context omitted.

It just an anchor. If it were 50k would you say the same down to 25k? And if so how many more times would it apply? The interesting thing is that it was manageable solo (in many ways it's _more_ manageable solo+AIs than with coworkers+(their)AIs), and in such a short amount of time.

Original RSL library is 36k LoC. And this is C++. Rust should be like 50% smaller, that is, 18k LoC. This library is so big that I bet the author has no idea if it works or not. 1300 test generated by AI say nothing about actual quality. In the end it is just a lot of unmaintainable code quickly generated by AI.

I see no reason for Rust to be shorter than C++,. when using latest standards.

Re: Learnings from 100K lines of Rust with AI (2025)

#156

Post by digitaltrees »

giancarlostoro wrote: post #102
chadd wrote: post #54

We're working on a large Rust codebase, heavily assisted development with Claude and Codex, and one critical workflow is after you have written a spec, have the other LLM critique it thoroughly. This back and forth will take quite a while, but the resulting implementation plan will be 10x better than the original. You can automate this by giving Codex a goal, and a skill to call Claude to review the implementation sp…

This is precisely how I used to use Beads before I made GuardRails (I wanted something slightly simpler, but similar with more 'guard rails'). I braindump everything I want to build, I ask Claude to do market level research. I then ask Claude to ask clarifying questions, when I ask Claude to be critical of its conclusions and provide the top options and to justify it. I also question Claude and say its okay to disagr…

I’ll check this out. I might integrate it in to my IDE (www.propelcode.app) as a complement to plan mode.

Re: Learnings from 100K lines of Rust with AI (2025)

#157

Post by pjmlp »

jgilias wrote: post #148
faangguyindia wrote: post #89

Earlier quoted context omitted.

This is why I suggested Go. Rust doesn't add anything over Go for LLM coding.

But it does. A whole class of runtime errors you can trivially produce in safe Go — null pointer dereferences, unchecked type assertions, missed enum cases — are unrepresentable in safe Rust. Also, the type system is a lot more expressive, so more invariants can be encoded in it, leading to more business logic bugs being caught at compile time rather than in production.

For that I would chose neither, rather go with Haskell, OCaml, F#, Lean, Dafny, FStar, Scala, Kotlin,...

Re: Learnings from 100K lines of Rust with AI (2025)

#158

Post by digitaltrees »

ai_fry_ur_brain wrote: post #62
chadd wrote: post #54

We're working on a large Rust codebase, heavily assisted development with Claude and Codex, and one critical workflow is after you have written a spec, have the other LLM critique it thoroughly. This back and forth will take quite a while, but the resulting implementation plan will be 10x better than the original. You can automate this by giving Codex a goal, and a skill to call Claude to review the implementation sp…

I hate how seriously people take the output of an LLMs or how reliable they think it is. Have Claude produce that spec 10 times, use the same prompt and same context. Identical requests, but you'll get 10 unique answers that wil contradict each other with each response seeming extermely confident. Its scary how confident you people are in these outputs.

But those differences fall within a band of generally accepted results don’t they? And the cost to throw the code away and reimplement is low now. So maybe it doesn’t really matter if the implementation is perfect or identical.

That being said I agree people trust AI too much. Especially people with less experience. It’s easy to forget the models are mirrors of we are as the drivers of the input context not mentors that will guide us to best practices reliably.

Re: Learnings from 100K lines of Rust with AI (2025)

#159

Post by digitaltrees »

b40d-48b2-979e wrote: post #72
CrazyStat wrote: post #69

Earlier quoted context omitted.

If you ask 10 different humans to produce the spec with the same information (prompt and context) they will also produce 10 unique answers that will contradict each other and (depending on who you asked) may be just as confident. There are real decisions to be made when going from a vague prompt to a spec. It's not surprising that an LLM would produce different specs for the same work on different runs. If the prompt…

LLMs aren't people. They don't reason. They're token generators, a black box. Your analogy falls on its face with any scrutiny.

Aren’t people pattern matching neural networks as well? Why does being a token generator mean something is unreliable?

Further, why does that mean “it doesn’t reason”. Logic can be encoded in language, symbols or code. If I say “all apples are red” -> “all fruit in the bowl are apples” -> “therefor all the fruit are red”. It doesn’t really matter if I understand the logic or what red is or fruit/apples are, the logic is contained in the structure of the syntax. If an LLM can output the conclusion reliably from predictive operations it is able to have the effect of reason and we don’t need to know or care about whether it “understands” the reasoning.

Re: Learnings from 100K lines of Rust with AI (2025)

#160

Post by digitaltrees »

claytongulick wrote: post #123
dnautics wrote: post #84

Earlier quoted context omitted.

LLMs do reason (they just sometimes don't reason well ). I assure you I've met many devs and "engineers" that reason less than LLMs, and are black boxes, especially in terms of the code they write.

> LLMs do reason No, they don't. They are token predictors that use statistical techniques to emit the randomly weighted next most likely token given the previous token list. The result is a strange mimic of human reasoning, because the tokens it predicts are trained on strings that were produced by humans that were reasoning, but that's not the same thing. Human cognition is complex and poorly understood, and the na…

The structure of language encodes logic in many ways. So the models ability to reason may be an emergent property of the reasoning ability humanity has ejected an extracted from our neural networks and abstracted into language a symbols.
Post reply on HN