Thread

1. tazjin · 1790799051 · focus · HN ↗

   > 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.

   1. minimaxir · 1790800261 · focus · HN ↗

      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.

      1. culi · 1790800450 · focus · HN ↗

         I wouldn't be surprised if we're already at the point of more LLM-written Rust than hand-written. Models training off models
      2. LarsDu88 · 1790801217 · focus · HN ↗

         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

         1. bitexploder · 1790801926 · focus · HN ↗

            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' :)
         2. rafram · 1790802218 · focus · HN ↗

            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.

            1. nchie · 1790804915 · focus · HN ↗

               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?

               1. zahlman · 1790842412 · focus · HN ↗

                  Couldn't it just look at what std::collections does?
            2. Karrot_Kream · 1790812255 · focus · HN ↗

               A good eval benchmark suite could really improve this then.
            3. hbbio · 1790814904 · focus · HN ↗

               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&#x27;re curious: <a href="https:&#x2F;&#x2F;github.com&#x2F;okcontract&#x2F;oksolc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;okcontract&#x2F;oksolc

            4. fireant · 1790833091 · focus · HN ↗

               TBH a &quot;global arena thing&quot; can be very good for performance rather than a bunch of random allocations&#x2F;deallocations
         3. lossolo · 1790805242 · focus · HN ↗

            Not always. In my experience, if you&#x27;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&#x2F;borrow checker.
         4. throwitaway222 · 1790807973 · focus · HN ↗

            I&#x27;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&#x2F;React).
         5. iillexial · 1790841714 · focus · HN ↗

            in my experience LLMs write pretty bad Rust code. sure it works, strong typing system, etc., but it&#x27;s unmaintainable and not readable.

            1. konart · 1790845997 · focus · HN ↗

               I doubt these two features will be a defining quality of a product soon enough.

               Many pieces of software are going to be just blackboxes worked by AI. You will be maintaining output quality and stability and that&#x27;s it.

            2. david-gpu · 1790846118 · focus · HN ↗

               I have the same problem with the assembly produced by compilers.

               Maybe we should let them do their thing and instead focus our attention on the higher-level stuff like specifications and testing.

      3. adamrezich · 1790801309 · focus · HN ↗

         All the main agents can write Jai code reasonably well despite being even more scarce in input data!
      4. 6thbit · 1790802872 · focus · HN ↗

         Have each agent rewrite openssl in $lang and call it the RollYourOwnCrypto bench.
      5. DrBenCarson · 1790807994 · focus · HN ↗

         From DARPA’s “Translating all C to Rust” TRACTOR program:

         <a href="https:&#x2F;&#x2F;www.ll.mit.edu&#x2F;r-d&#x2F;projects&#x2F;translating-all-c-rust-tractor-benchmarks" rel="nofollow">https:&#x2F;&#x2F;www.ll.mit.edu&#x2F;r-d&#x2F;projects&#x2F;translating-all-c-rust-t...

         1. ksec · 1790843695 · focus · HN ↗

            I wonder why not to Ada or SPARK.

Unofficial Hacker News client; not affiliated with Y Combinator.