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 an hour ago | parent | next [-]

  > 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 5 minutes ago \| parent [-]
		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.

▲ cyode 6 hours ago | parent | prev | next [-]

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 4 hours ago | parent [-]

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 4 hours ago \| parent \| next [-]
		> 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.
	▲	ukblewis 4 hours ago \| parent \| prev \| next [-]
		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!
	▲	arduanika 2 hours ago \| parent \| prev [-]
		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.

▲ chupchap 41 minutes ago | parent | prev | next [-]

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

▲ hparadiz 3 hours ago | parent | prev | next [-]

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 3 hours ago | parent | prev [-]

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