[jp1016]

The byte-for-byte identical output requirement is the smartest part of this whole thing. You basically get to run the old and new pipelines side by side and diff them, which means any bug in the translation is immediately caught. Way too many rewrites fail because people try to "improve" things during the port and end up chasing phantom bugs that might be in the old code, the new code, or just behavioral differences.

Also worth noting that "translated from C++" Rust is totally fine as a starting point. You can incrementally make it more idiomatic later once the C++ side is retired. The Rust compiler will still catch whole classes of memory bugs even if the code reads a bit weird. That's the whole point.

[godelski]

  > Way too many rewrites fail because people try to "improve" things during the port

I'd say that porting is a great time to "improve" many things, but like you suggest, not a great time to add new features. You can do a lot of improvements while maintaining output parity. You're in the weeds, reading the code, thinking about the routines, and you have all the hindsight of having done it already. Features are great to add as comments that sketch things out but importantly this is a great time to find and recognize that maybe a subroutine is pretty inefficient. I mean the big problem in writing software is that the goal are ever evolving. You wrote the software for different goals, different constraints. So a great time to clean things up, make them more flexible, more readable, *AND TO DOCUMENT*.

I think the last one gets ignored easily but my favorite time to document code is when reading it (but the best time is when writing it). It forces you to think explicitly about what the code is doing and makes it harder for the little things to slip by. Given that Ladybird is a popular project I really do think good documentation is a way to accelerate its development. Good documentation means new people can come in and contribute faster and with fewer errors. It lowers the barrier to entry, substantially. It's also helpful for all the mere mortals who forget things

[JuniperMesos]

LLMs are great at producing documentation - ask one "hey can you add a TODO comment about the thing on line 847 that is probably not the best way to do this?" while you're working on the port, and it will craft a reasonably-legible comment about that thing without further thought from you, that will make things easier for the person (possibly future-you) looking at the codebase for improvements to make. Meanwhile, you keep on working on the port that has byte-for-byte identical output.

[al_borland]

If I’m writing that anyway, to tell the LLM, why wouldn’t I just write the comment myself?

[ale42]

I guess to have the LLM write a lengthy descrption of why the code is bad? Otherwise it doesn't make sense to ask an LLM instead of typing // TODO: bad coding style.

[godelski]

Why do I want length? Good docs are terse. Longer isn't better. When I read docs I want to get to know the developer and what they're thinking. I want to see their vision, not their calculator. It's not about quantity, it's about quality.

Just give your users and fellow devs some basic respect. I mean would you be okay with me just handing our conversation over to an LLM? Honestly I'd be insulted if you did that. Why is this any different? Docs are how you communicate to users and fellow developers

[JuniperMesos]

Concision is one of several virtues in documentation, and it trades off against thoroughness. I don't actually want to get to know the developer when I read a comment in some piece of code I am reading or editing, I want to as quickly and accurately as possible understand what I need to know about that code to make the changes I care about at that time.

Anyway I personally have asked LLMs to create more detailed TODO items for myself, on personal projects where I am the only human programmer who had laid eyes on the code. In fact, I do this frequently, including multiple times earlier today. So I don't take the idea seriously that using an LLM to generate a TODO comment is an inherently disrespectful thing to do.

[ale42]

I didn't say that length was a requirement, I was only thinking about why one would want to use an LLM to write a comment that is only a few words long, while the prompt might be as long as the (short version of the) comment itself.

[cyode]

I hope, with the velocity unlocked by these tools, that more pure ports will become the norm. Before, migrations could be so costly that “improving” things “while I’m here” helped sell doing the migration at all, especially in business settings. Only to lead to more toil chasing those phantom bugs.

[ozgrakkurt]

One of the biggest point of rewriting is you know better by then so you create something better.

This is a HUUUGE reason code written in rust tended to be so much better than the original (which was probably written in c++).

Human expertise is the single most important factor and is more important than language.

Copy pasting from one language to another is way worse than complete rewrite with actual idiomatic and useful code.

Best option after proper rewrite is binding. And copy-paste with LLM comes way below these options imo.

If you look at real world, basically all value is created by boring and hated languages. Because people spent so much effort on making those languages useful, and other people spent so much effort learning and using those languages.

Don’t think anyone would prefer to work in a rust codebase that an LLM copy-pasted from c++, compared to working on a c++ codebase written by actual people that they can interact with.

[palata]

> Copy pasting from one language to another is way worse than complete rewrite with actual idiomatic and useful code.

But translating with automated tools is a much faster experiment.

Sometimes (not always), rewriting from scratch ends up in a big loss of time and resources and never replaces the old version.

[drzaiusx11]

I've seen more than a few rewrite attempts fail throughout the years. However, I've never seen a direct language to language translation fail. I've done several of these personally: from perl to ruby, java to kotlin, etc.

Step 1 of any rewrite of a non-trivial codebase should should be parity. You can always refactor to make things more idiomatic in a later phase.

[arduanika]

These are two different kinds of rewrites, for two different kinds of codebases, in two different situations. The important thing is to know which kind of rewrite you're doing, and have the whole team onboard.

The sort of rewrite you're talking about can work well at an early stage of a project, in the spirit of Fred Brooks's "plan to throw one away". But for a mature browser like Ladybird that's trying to not break the user experience, it's much better to have a pure translation step, and then try to improve or refactor it later.

[ukblewis]

It depends on your goals. If your only initial goal is to ensure the safety of your code, and that is rather important for a browser!

[Foobar8568]

I rewrote two times my personal tool, one to rust, and out of rust with LLM, I mainly "vibe code" for reasons but the tool is more complete and less buggy than most B2B and enterprise business or IT software that I have seen in 20years at different fortune 100.

I feel the effort and frustration to have parity with LLM is more than doing a full rewrite without.

[sobani]

That reminds me of the "Strangler Fig" pattern where you replace a service by first sending the requests to both the old and new implementation so you can compare their outputs. Then only when you're confident the new service functions as expected do you actually retire the old service.

[CuriouslyC]

The key part of the strangler fig is the facade and gradual migration of capabilities rather than trying to do a rewrite and swap (which never ends well).

[hparadiz]

I did several web framework conversions exactly like this. Make sure the http output string matches in the new code exactly as the old code and then eventually deleted the old code with full confidence.

[dreis_sw]

Works even better if you have a good test suite, which is surely the case here with Ladybird

[chupchap]

Really like this translation approach and I had written about it just couple of days back (more from a testing and validation context). To see folks take that approach to something complex is pretty amazing! https://balanarayan.com/2026/02/20/gen-ai-time-to-focus-on-l...