> Argon agents are working on migrating C/C++ codebases to Rust across Google
Man, I remember back in the days when the cppnext team was refusing to even consider Rust, instead looking at absurd stuff like Carbon and Swift (!), even though half of the engineering staff already knew where this was headed. I hope they got a few good promos out of the delays at least.
A RewriteInRustBench would be unironically useful at this point since all the main agents can write it reasonably well despite its relative scarcity in the input data.
Rust is the best language for LLMs b/c it gives by far the best debug messages. Just tons of verifiable reward signal for post-training. Even the most rudimentary LLMs can school me on idiomatic Rust
Evidence needed. I think for certain kinds of outcomes it has very strong advantages, but these advantages are not a given as 'best for LLMs' :)
On the other hand, Rust's borrow checker is very picky, and even a frontier LLM still sometimes struggles to respond to roadblocks sensibly (refactoring so whatever it's trying to do can be done safely) rather than stupidly (introducing some horrible global arena thing so it can make the borrow checker go away). A lot depends on how good your instructions are, and how good the existing code is, since bad input begets bad output.
I've (more or less; I've read quite a bit of the code) vibecoded several houndred thousand lines of Rust and I've not seen this happen a single time. It sounds like something it'd do when you ask it to "write a linked list while satisfying the borrow checker". Are you sure you haven't (possibly) unknowingly been giving it instructions which ended up luring it into doing these things?
Yep! In our tests, we found Zig to be a pretty good fit to translate C++ codebases.
And static analysis + agents are good enough at keeping the memory management in check. Compared to Rust, there's no magic so it's easy for devs and agents to reason about.
If you're curious: <a href="https://github.com/okcontract/oksolc" rel="nofollow">https://github.com/okcontract/oksolc
Not always. In my experience, if you're not working on a small, trivial codebase, LLMs will sometimes just create spaghetti unreadable, inefficient code to satisfy the constraints of the type system/borrow checker.
I've narrowed in on only using Go or Rust generated code (Go for APIs right now) and rust for some TUI or other thing. TS for web interfaces (w/React).
tazjin · · focus · HN ↗
Man, I remember back in the days when the cppnext team was refusing to even consider Rust, instead looking at absurd stuff like Carbon and Swift (!), even though half of the engineering staff already knew where this was headed. I hope they got a few good promos out of the delays at least.
minimaxir · · focus · HN ↗
LarsDu88 · · focus · HN ↗
bitexploder · · focus · HN ↗
rafram · · focus · HN ↗
nchie · · focus · HN ↗
zahlman · · focus · HN ↗
Karrot_Kream · · focus · HN ↗
hbbio · · focus · HN ↗
And static analysis + agents are good enough at keeping the memory management in check. Compared to Rust, there's no magic so it's easy for devs and agents to reason about.
If you're curious: <a href="https://github.com/okcontract/oksolc" rel="nofollow">https://github.com/okcontract/oksolc
fireant · · focus · HN ↗
lossolo · · focus · HN ↗
throwitaway222 · · focus · HN ↗
iillexial · · focus · HN ↗
konart · · focus · HN ↗
Many pieces of software are going to be just blackboxes worked by AI. You will be maintaining output quality and stability and that's it.
david-gpu · · focus · HN ↗
Maybe we should let them do their thing and instead focus our attention on the higher-level stuff like specifications and testing.