1272 points by adius 6 days ago | 698 comments on HN
| Moderate positive
Contested
Editorial · v3.7· 2026-02-26 04:24:24 0
Summary Knowledge & Participation Advocates
This technical blog post documents Ladybird browser's adoption of Rust, emphasizing transparent decision-making, collaborative development methodology with human-directed AI assistance, and open-source participation. The content engages primarily with Article 19 (freedom of expression and access to information) and Article 27 (participation in cultural and scientific life) through openly accessible technical documentation, identified authorship, and emphasis on community coordination in development processes.
> We know the result isn’t idiomatic Rust, and there’s a lot that can be simplified once we’re comfortable retiring the C++ pipeline. That cleanup will come in time.
Correct me if I’m wrong since I don’t know these two languages, but like some other languages, doing things the idiomatic way could be dramatically different. Is “cleanup” doing a lot of heavy lifting here? Could that also mean another complete rewrite from scratch?
A startup switching languages after years of development is usually a big red flag. “We are rewriting it in X” posts always preceded “We are shutting down”. I wish them luck though!
> 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.
I'm a long-time Rust fan and have no idea how to respond. I think I need a lot more info about this migration, especially since Ladybird devs have been very vocal about being "anti-rust" (I guess more anti-hype, where Rust was the hype).
I don't know if it's a good fit. Not because they're writing a browser engine in Rust (good), but because Ladybird praises CPP/Swift currently and have no idea what the contributor's stance is.
At least contributing will be a lot nicer from my end, because my PR's to Ladybird have been bad due to having no CPP experience. I had no idea what I was doing.
A lot of the previous calculus around refactoring and "rewrite the whole thing in a new language" is out the window now that AI is ubiquitous. Especially in situations where there is an extensive test suite.
All the best to them, however this feels like yah shaving instead of focusing into delivering a browser than can become an alternative to Safari/Chrome duopoly.
I know he doesn't make live coding videos anymore, but it'd be cool if Andreas showed off how this worked a little more. I'm curious how much he had to fix by hand (vs reprompting or spinning a different model or whatever).
> We previously explored Swift, but the C++ interop never quite got there, and platform support outside the Apple ecosystem was limited.
Why was there ever any expectation for Swift having good platform support outside Apple? This should have been (and was to me) already obvious when they originally announced moving to Swift.
Very happy to see this. Ladybird's engineering generally seems excellent, but the decision to use Swift always seemed pretty "out there". Rust makes a whole lot more sense.
Cool, that seems like a rational choice. I hope this will help Ladybird and Servo benefit from each other in the long run, and will make both of them more likely to succeed
Someone should try this with the “Ralph Wiggum loop” approach. I suspect it would fail spectacularly, but it would be fascinating to watch.
Personally, I can’t get meaningful results unless I use the tool in a true pair-programming mode—watching it reason, plan, and execute step by step. The ability to clearly articulate exactly what you want, and how you want it done, is becoming a rare skill.
> We know the result isn’t idiomatic Rust, and there’s a lot that can be simplified once we’re comfortable retiring the C++ pipeline. That cleanup will come in time.
I wonder what kind of tech debt this brings and if the trade off will be worth whatever problems they were having with C++.
Looks like Andreas is a mighty fine engineer, but he's even better entrepreneur. Doesn't matter if intentional or not, but he managed to create and lead a rather visible passion project, attract many contributors and use that project's momentum to detach Ladybird into a separate endeavor with much more concrete financial prospects.
The Jakt -> Swift -> Rust pivots look like the same thing on a different level. The initial change to Swift was surely motivated by potential industry support gain (i believe it was a dubious choice from purely engineering standpoint).
It's awe-inspiring to see how a person can carve a job for himself, leverage hobbyists'/hackers' interest and contributions, attract industry attention and sponsors all while doing the thing he likes (assuming, browsers are his thing) in a controlling position.
Can't fully rationalize the feeling, but all of this makes me slightly wary. Doesn't make it less cool to observe from a side, though.
> After the initial translation, I ran multiple passes of adversarial review, asking different models to analyze the code for mistakes and bad patterns.
I feel like you just know it’s doomed. What this is saying is “I didn’t want to and cannot review the code it generated” asking models to find mistakes never works for me. It’ll find obvious patterns, a tendency towards security mistakes, but not deep logical errors.
Porting the JS parser to Rust and adopting Rust in other parts of the engine while continuing to use C++ heavily is unlikely to make Ladybird meaningfully more secure.
Attackers are surprisingly resilient to partial security.
> This is not becoming the main focus of the project. We will continue developing the engine in C++, and porting subsystems to Rust will be a sidetrack that runs for a long time.
I don't like this bit. Wouldn't it be better to decide on a memory-safe language, and then commit to it by writing all new code in Rust, or whatever. This looks like doing double the work.
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.
A LLM-assisted codebase migration is perhaps one of the better use cases for them, and interestingly the author advocates for a hands-on approach.
Adding the "with help from AI" almost always devolves the discussion from that to "developers must adopt AI or else!" on the one hand and "society is being destroyed by slop!" on the other, so as long as that's not happening I'm not complaining about the editorialized title.
You can do it via the C ABI, and use opaque pointers to represent higher-level Rust/C++ concepts if you want to.
Firefox is a mixed C++ / Rust codebase with a relatively close coupling between Rust and C++ components in places (layout/dom/script are in C++ while style is in Rust, and a mix of WebRender (Rust) and Skia (C++) are used for rendering with C++ glue code)
This is the famous trap that Joel on Software talked about in a blog post long time ago.
If you do a rewrite you essentially put everything else on halt while rewriting.
If you keep doing feature dev on the old while another "tiger team" is doing the rewrite port then these two teams are essentially in a race against each other and the port will likely never catch up. (Depending on relative velocities)
Maybe they think that they can to this LLM assisted tools in a big bang approach quickly and then continue from there without spending too much time on it.
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".
I think we've come to the point when it should be the opposite for any new code, something in line of: "done without AI". Bein an old fart working in software development I have many friends working as very senior developers. Every single one of them including yours truly uses AI.
I use AI more and more. Goes like create me classes A,B,C with such and such descriptive names, take this state machine / flowchart description to understand the flow and use this particular sets of helpers declared in modules XYZ
I then test the code and then go over and look at any un-optimal and other patterns I prefer not to have and asking to change those.
After couple of iterations code usually shines. I also cross check final results against various LLMs just in case
A mitigating factor in this case is the C++ and Rust are both multi-paradigm languages. You can quite reasonably represent most C++ patterns in Rust, even if it might not be quite how you'd write Rust in the first place.
> 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.
Yeah, that part doesn't make much sense to me. IMO, Swift has reasonably good C++ interop[1] and Swift's C interop has also significantly improved[2] since Swift 6.2.
I am somewhat concerned about the volatility. All three languages have their merits and each has a stable foundation that has been developed and established over many years. The fact that the programming language has been “changed” within a short period of time, or rather that the direction has been altered, does not inspire confidence in the overall continuity of Ladybird's design decisions.
Agreed. They said they ruled out rust in 2024, I believe the article they published was near the end of 2024 because I remember reading it fairly recently.
Seems like a lot of language switches in a short time frame. That'd make me super nervous working on such a project. There will be rough parts for every language and deciding seemingly on whims that 1 isn't good enough will burn a lot of time and resources.
Part of browser experience is safety and migrating their JS library to Rust is probably one of the best ways to gain advantage over any other existing engine out there in this aspect. Strategically this may and likely will attract 3rd party users of the JS library itself, thus helping its adoption and further improving it.
They're not porting the browser itself to Rust, for the record.
Given the quality of their existing test suite I'm confident the Ralph Wiggum loop would produce a working implementation... but the code quality wouldn't be anywhere near what they got from two weeks of hands-on expert prompting.
What happened? It’s been awhile since I checked in but it seems he doesn’t work on serenity and doesn’t live stream anymore (and is now into lifting weights)
Andreas Kling mentioned many times they would prefer a safer language, specifically for their js runtime garbage collector.
But since the team were already comfortable with cpp that was the choice, but they were open and active seeking alternatives.
The problem was strictly how cpp is perceived as an unsafe language, and this problem rust does solve!
Not being sarcastic, this truly looks like a mature take. Like, we don't know if moving to rust would improve quality or prevent vulnerabilities, here's our best effort to find out and ignore if the claim has merits for now. If the claim maintains, well, you're better prepared, if it doesn't, but the code holds similar qualities...what is the downside?
Content documents participation in open-source software development, collaboration with AI tools, and technical decision-making that benefits the commons; explicit discussion of community coordination and transparent process.
FW Ratio: 57%
Observable Facts
Post describes use of AI assistance (Claude Code and Codex) in a collaborative, human-directed manner within technical development.
Author emphasizes community coordination: 'Please coordinate with us before starting any porting work so nobody wastes their time.'
Content is published openly with identified authorship, supporting participation in shared knowledge creation about browser technology.
References to test262 and public regression testing demonstrate transparent verification of work.
Inferences
Documentation of collaborative development process with human oversight of AI tools supports participation in technical culture.
Emphasis on coordination and managed porting effort reflects concern for efficient community participation.
Open publication of technical methodology enables others to participate in and learn from development practices.
Content presents detailed technical reasoning about language choice and development methodology, supporting informed public discourse on technology decisions.
FW Ratio: 60%
Observable Facts
Author explicitly identifies himself as 'Andreas Kling, Founder & President' and explains technical decision-making transparently.
Post provides detailed rationale for language adoption decision, testing methodology, and performance verification.
Content includes reference to publicly accessible code repository and test262 benchmark suite.
Inferences
Transparent attribution and detailed technical explanation support informed public discourse on development decisions.
Open accessibility and reference to public code repositories enable broader participation in knowledge about browser technology.
build 1ad9551+j7zs · deployed 2026-03-02 09:09 UTC · evaluated 2026-03-02 10:41:39 UTC
Support HN HRCB
Each evaluation uses real API credits. HN HRCB runs on donations — no ads, no paywalls.
If you find it useful, please consider helping keep it running.