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

181–190 of 225 posts

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

#181

Post by keeganpoppen »

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…

there is absolutely no line of demarcation between human reasoning and what you described

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

#182

Post by DeathArrow »

rurban wrote: post #64
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…

I see the complete opposite. The lower level the language, the less babysit the agent. Pure asm is the best, only with very advanced SIMD flags it has problems. C is excellent. But python or typescript are full of errors all the time. I rather fallback to perl than python. Perl has been excellent all along.

It makes sense. In a lower level language most mistakes would break the software hard and the AI will notice it. Python and JS are happy to run with lots of bugs.

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

#184

Post by esailija »

IshKebab wrote: post #143
b40d-48b2-979e wrote: post #72

Earlier quoted context omitted.

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

Wow, there are still people trying to claim they don't reason. What will they have to do before you'll admit that they can?

You are asking the wrong question. It's not about if you can do X which can be faked especially if you are given practically infinite tries and all failures are hidden.

The people who want to believe they actually reason just ignore all obvious evidence of contrary and cherry pick the times reasoning was faked well enough.

The people who don't want to believe will just take a second to understand how they work and then come up with ways to reveal they were faking all along. Like asking how many letters there are in a word lol.

It's only the people who don't want to believe that count because reality is what happens despite of what you believe.

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

#186

Post by kimixa »

keeganpoppen wrote: post #175
knivets wrote: post #103

Earlier quoted context omitted.

This is astrology for devs.

as someone who is about as llm-forward as anyone out there, this is a brilliant analogy. was equally true of all the “prompt engineer” hype as well from a couple years ago (which i admit i still think does matter)… it kinda makes me feel like an audiophile / hi-fi person talking about how 24bit/192kHz is the one true encoding format and anything less is a willfull (cynical, “Quality”-hating, satisficerist, etc.) comp…

For higher than audible frequency sample rates there's a good chance you can tell the difference. It often causes weird aliasing and harmonics in the more audible frequencies on "real" playback equipment. You can train yourself to recognize some of these and often pretty accurately identify the higher sample rate examples. You might even mentally associate those signs with "Higher Quality".

But it's arguably less accurate to the original recording.

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

#187

Post by mike_hearn »

jdw64 wrote: post #21
faitswulff wrote: post #17

Earlier quoted context omitted.

What kinds of programs are you writing and with what models? I'm curious if the lifetimes your programs require are trickier than most.

I'm actually vibe coding a game engine right now using a Hexagonal Architecture, and I ran into this exact same issue when trying to synchronize the feedback loop between the viewport and the editor. To be fair, I probably messed up the domain boundaries myself in the first place, but honestly, the AI-generated code wasn't very effective at solving it either

Game engines are one of the worst case scenarios for something like Rust as game heaps are simulations of the real world, so have lots of complex graph structures in them. Affine types work best for request/response oriented stuff where lifetimes are clearly bounded.

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

#188

Post by raincole »

knivets wrote: post #103
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 astrology for devs.

People though asking LLM to output the reasoning steps was astrology until it's standardized and made ubiquitous.

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

#189

Post by luckystarr »

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…

I tried coding "ownership strictly" in Rust myself for a while and I've given up for the most part. In a lot of cases I painted myself into corners that I couldn't get out from without changing everything. That is probably a signal I should use, but Arc and clone also work. So I use them.

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

#190

Post by flossly »

risyachka wrote: post #6
torben-friis wrote: post #4

>Testing is the first layer of defense. My system now includes 1,300+ tests — from unit tests to minimal integration tests (e.g., proposer + acceptor only), all the way to multi-replica full integration tests with injected failures. See the project status. I know LOC is a silly metric, but ~1300 tests for 130k lines averages out to a test per 100 lines - isn't this awfully low for a highly complex piece of code, even…

I may have missed it but are those tests written by person or generated? Otherwise how do you know they even test anything (like actually test, not appear to test)

Ask AI to find the weakest tests. :)

No joke: it works for me. I have a 45kLOC prod code (just code, no comments, no blanks), tested by a 30kLOC test code containing 1600 tests (that run in 30secs).

I helped with the test infrastructure/architecture. Sometimes I had to write the first few tests of a particular kind, but now Claude TDDs for me.

A fair share of my CLAUDE.md instructs in how I like my tests, when to write them (first), different types of tests (unit, faked-services, db, e2e, etc.)

Asking Claude to find weak tests has helped a lot in getting here. I also do review AI-gen'd code, pretty much line-by-line, before accepting it.

Post reply on HN