alt Hacker News> I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go. After the initial translation, I ran multiple passes of adversarial review, asking different models to analyze the code for mistakes and bad patterns. > The requirement from the start was byte-for-byte identical output from both pipelines. The result was about 25,000 lines of Rust, and the entire port took about two weeks. The same work would have taken me multiple months to do by hand. We’ve verified that every AST produced by the Rust parser is identical to the C++ one, and all bytecode generated by the Rust compiler is identical to the C++ compiler’s output. Zero regressions across the board
This is the way. Coding assistants are also really great at porting from one language to the other, especially if you have existing tests.
Replies
> Coding assistants are also really great at porting from one language to the other
I had a broken, one-off Perl script, a relic from the days when everyone thought Drupal was the future (long time ago). It was originally designed to migrate a site from an unmaintained internal CMS to Drupal. The CMS was ancient and it only ran in a VM for "look what we built a million years ago" purposes (I even had written permission from my ex-employer to keep that thing).
Just for a laugh, I fed this mess of undeclared dependencies and missing logic into Claude and told it to port the whole thing to Rust. It spent 80 minutes researching Drupal and coding, then "one-shotted" a functional import tool. Not only did it mirror the original design and module structure, but it also implemented several custom plugins based on hints it found in my old code comments.
It burned through a mountain of tokens, but 10/10 - would generate tens of thousands of lines of useless code again.
The Epilogue: That site has since been ported to WordPress, then ProcessWire, then rebuilt as a Node.js app. Word on the street is that some poor souls are currently trying to port it to Next.js.
Agree, and it's also such a shame that none of the AI companies actually focus on that way of using AI.
All of them are moving into the direction of "less human involved and agents do more", while what I really want is better tooling for me to work closer with AI and be better at reviewing/steering it, and be more involved. I don't want "Fire one prompt and get somewhat working code", I want a UX tailored for long sessions with back and forth, letting me leverage my skills, rather than agents trying to emulate what I already can do myself.
It was said a long time ago about computing in general, but more fitting than ever, "Augmenting the human intellect" is what we should aim for, not replacing the human intellect. IA ("Intelligence amplification") rather than AI.
But I'm guessing the target market for such tools would be much smaller, basically would require you to already understand software development, and know what you want, while all AI companies seem to target non-developers wanting to build software now. It's no-code all over again essentially.
I am learning rust myself and one of the things I definetly didn't want to do was let Claude write all the code. But I needed guidance.
I decided to create a Claude skill called "teach". When I enable it, Claude never writes any code. It just gives me hints - progressively more detailed if I am stuck. Then it reviews what I write.
I am finding it very satisfying to work this way - Rust in particular is a language where there's little space to "wing it". Most language features are interlaced with each other and having an LLM supporting me helps a lot. "Let's not declare a type for this right now, we would have to deal with several lifetime issues, let's add a note to the plan and revisit this later".
This is also how some of us use Claude despite what the haters say. You dont just go “build thing” you architect, review, refine, test and build.
I haven’t done a ton of porting. And when I did, it was more like a reimplementation.
> We’ve verified that every AST produced by the Rust parser is identical to the C++ one, and all bytecode generated by the Rust compiler is identical to the C++ compiler’s output.
Is this a conventional goal? It seems like quite an achievement.
This is the way. This exact workflow is my sweet spot.
In my coding agent std::slop I've optimized for this workflow https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode... basically the idea is that you are the 'maintainer' and you get bisect safe, git patches that you review (or ask a code reviewer skill or another agent to review). Any change re-rolls the whole stack. Git already supports such a flow and I added it to the agent. A simple markdown skill does not work because it 'forgets'. A 'github' based PR flow felt too externally dependent. This workflow is enforced by a 'patcher' skill, and once that's active, tools do not work unless they follow the enforced flow.
I think a lot of people are going to feel comfortable using agents this way rather than going full blast. I do all my development this way.
I had a script in another language. It was node, took up >200MB of RAM that I wanted back. "claude, rewrite this in rust". 192MB of memory returned to me.
> This was human-directed, not autonomous code generation.
All my vibe coded projects are human directed, unless explicitly stated otherwise
Coding assistants are great at pattern matching and pattern following. This is why it’s a good idea to point them at any examples or demos that come with the libraries you want to use, too.
I am having immense success with the latest models developing a personal project that I open sourced and then got burned off by.I can't write anymore by hands but I do enjoy writing prompts with my voice.I have been shipping the best code the project has ever seen.The revolution is real.
Quite good. I ported my codebase from Go to Rust in a fraction of the time it would have taken me to rewrite it.
I had a bash spaghetti code script that I wrote a few years ago to handle TLS certificates(generate CSRs, bundle up trust chains, match keys to certs, etc). It was fragile, slow, extremely dependent on specific versions of OpenSSL, etc.
I used Claude to rewrite it in golang and extend its features. Now I have tests, automatic AIA chain walking, support for all the DER and JKS formats, and it’s fast. My bash script could spend a few minutes churning through a folder with certs and keys, my golang version does a few thousand in a second.
So I basically built a limited version of OpenSSL with better ergonomics and a lot of magic under the hood because you don’t have to specify input formats at all. I wasn’t constrained by things like backwards compatibility and interface stability, which let me make something much nicer to use.
I even was able to build a wasm version so it can run in the browser. All this from someone that is not a great coder. Don’t worry, I’m explicitly not rolling my own crypto.