Live data from Hacker News

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

zfhuang99.github.io

31–40 of 225 posts

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

#32
post #30
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.

If I was forced to write it myself, then I'd agree, I'd use Clojure all day before Rust, because it's such a chore to write, edit and read.

The whole "with AI" kind of reduces my hate for Rust though, and increases the appreciation for how strict the language is, especially when the agents themselves does the whole "do change > see error/warning > adjust code > re-check > repeat" loop themselves, which seems to work better the more strict the language is, as far as I can tell.

The "helpful" error messages from Rust can be a bit deceiving though, as the agents first instinct seems to be to always try what the error message recommends, but sometimes the error is just a symptom of a deeper issue, not the actual root issue.

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

#33
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…

Lots and lots of guardrails to not allow slop.

In tsz I have hard gates that disallow doing work in the wrong crate etc.

https://github.com/mohsen1/tsz

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

#34
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…

I'm surprised to hear this. I have not had any issues here at all. The AI might clone things but I don't really care/ mind, I can ask it to refactor to make things zero-copy after, which is how I've often written Rust myself. I've never seen it overly wrap things in Rc.

I've not done any particular/ special prompting.

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

#35
post #28
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.

the interesting thing is how fast it becomes unmanagable.

Also that, I suspect that's correlated to how practical is to have multiple people (with their agents) iterating on it.

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

#36
post #29

Earlier quoted context omitted.

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

Sorry, should clarify. .clone() itself isn't inherently unidiomatic when used . My issue is specifically with how the AI uses it. In AI code, .clone() is almost always used as a brute-force escape hatch

So .clone() significantly reduces the mental overhead of using rust with a small performance impact? I'm intrigued :)

Maybe it's harder to reason about the lifetime semantics while also writing code, and works better as a second phase (the de-cloning).

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

#37
post #33
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…

Lots and lots of guardrails to not allow slop. In tsz I have hard gates that disallow doing work in the wrong crate etc. https://github.com/mohsen1/tsz

> have hard gates that disallow doing work in the wrong crate

Maybe I'm using agents wrong, but I'm not sure how you'd end up in that situation in the first place? When I start codex, codex literally only has access to the directory I'm launching it, with no way to navigate, read or edit stuff elsewhere on my disk, as it's wrapped in isolation with copied files into it, with no sync between the host.

Hearing that others seemingly let agents have access to their full computer, I feel like I'm vastly out of date about how development happens nowadays, especially when malware and virus lurks around all the package registries.

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

#38
post #5

Is the idea of the runtime contracts similar to the idea of runtime validation? Or are they different in some way?

It is described in the "Code Contracts" section of the article: "Code contracts specify preconditions, postconditions, and invariants for critical functions. These contracts are converted into runtime asserts during testing but can be disabled in production builds for performance". The .NET framework article that he links to: https://learn.microsoft.com/en-us/dotnet/framework/debug-tra...

Is this basically what Dijkstra was saying? I've been thinking how his approach was considered impractical, but may eventually become necessary for security/stability reasons the way things are going. (Seems like new zeroday on HN front page every day now.)

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

#39
post #29

Earlier quoted context omitted.

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

Sorry, should clarify. .clone() itself isn't inherently unidiomatic when used . My issue is specifically with how the AI uses it. In AI code, .clone() is almost always used as a brute-force escape hatch

Just like for me as an amateur Rust enjoyer then
Post reply on HN