The Ladybird browser project shifts to Rust [LWN.net]

The Ladybird browser project has announced a move to the Rust programming language:

When we originally evaluated Rust back in 2024, we rejected it because it's not great at C++ style OOP. The web platform object model inherits a lot of 1990s OOP flavor, with garbage collection, deep inheritance hierarchies, and so on. Rust's ownership model is not a natural fit for that.
But after another year of treading water, it's time to make the pragmatic choice. Rust has the ecosystem and the safety guarantees we need. Both Firefox and Chromium have already begun introducing Rust into their codebases, and we think it's the right choice for Ladybird too.

Large language models are being used to translate existing code.

to post comments

Not "moving"

Posted Feb 23, 2026 16:27 UTC (Mon) by rsidd (subscriber, #2582) [Link] (1 responses)

As the post makes clear, "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. New Rust code will coexist with existing C++ through well-defined interop boundaries."

Also, LLMs were used as a tool but with huge amounts of human vetting and validation, as per the blogpost.

Plus pitting LLM v. LLM.

Posted Feb 25, 2026 18:43 UTC (Wed) by ejr (subscriber, #51652) [Link]

The adversarial model of having an LLM's output reviewed by a *different* LLM is a great addition to a strong test suite. The former can catch more architectural mistakes than the latter.

Automated systems are never perfect even when automated by telling a person "do this". Hence reviews occur. A few rounds of automated review can be quite handy.

It's just an experiment, right?

Posted Feb 23, 2026 16:44 UTC (Mon) by NightMonkey (subscriber, #23051) [Link] (2 responses)

What’s next

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. New Rust code will coexist with existing C++ through well-defined interop boundaries.

We want to be deliberate about which parts get ported and in what order, so the porting effort is managed by the core team. Please coordinate with us before starting any porting work so nobody wastes their time on something we can’t merge.

I know this will be a controversial move, but I believe it’s the right decision for Ladybird’s future. :^)

It won't be controversial if you just say it is an experiment, which it sounds like it is. Nothing wrong with experiments! The most interesting thing will be what the next step *after* a non-idomatic conversion of the code from C++ to Rust will be. Can the code evolve, or will the impedance mismatch between a OOP/C++ idiom directly to non-idiomatic Rust create a giant cognitive bottleneck that stifles code evolution?

Cheers.

It's just an experiment, right?

Posted Feb 23, 2026 17:05 UTC (Mon) by rsidd (subscriber, #2582) [Link] (1 responses)

I'm not a part of the ladybird project, but my reading of that post is

It's not "just an experiment" -- the rewritten javascript engine will be used, and so will future rewritten pieces
They plan to port other parts
But there is no plan to "move"/"shift" to Rust, in particular, the main engine will continue to be developed in C++

It's just an experiment, right?

Posted Feb 23, 2026 18:38 UTC (Mon) by jmalcolm (subscriber, #8876) [Link]

I agree with your take.

However the "port via LLM" strategy most likely works dramatically better where there is very tight test coverage to heavily constrain the behaviour of the AI generated code. There are other places where this exists but, even with things like the Web Platform Tests, this approach is probably a lot more difficult for much of the Ladybird code base.

Once they port a few specific items via LLM, experienced Rust devs will probably look for modules that they can re-architect into something more idiomatic to Rust. This will be more dangerous and so will likely be a more drawn out process.

Firefox has shown that a shared C++/Rust codebase is workable. So, the C++ in Ladybird may be with us for a long time.

Nothing wrong with using Rust where its design brings the most value. The JavaScript engine was a great first candidate.

Thoughts on timing

Posted Feb 23, 2026 18:30 UTC (Mon) by jmalcolm (subscriber, #8876) [Link]

I was blindsided by this. Sounds like an April Fool joke almost. They evaluated Rust previously and I thought had rejected it completely (permanently). That said, I am excited to see them move to a safe language but surprised. Crazy that both "new" engines (Ladybird and Servo) may be Rust based going forward.

My next questions are about the timing and how this impacts the goal of having a "usable" preview mid-year. This seems like a massive undertaking to kick-off so close to that goal. Ladybird has made massive progress recently and being ready for early-adopters in a few months was feeling realistic. Then again, it is probably way easier and less risky to do it now than to try this immediately after telling people it is ready.

So perhaps this is the perfect time. Especially if they can get such outstanding results. Two weeks to have a functionally identical port of the entire JavaScript engine is pretty amazing. I guess it depends on how hard it is to refactor and iterate against the Rust version moving forward.

I wonder what they really mean by "experiment". If the entire JavaScript engine has been ported, it would make sense to migrate to it as the primary implementation. The JavaScript engine still sees heavy development. I cannot imagine that they will maintain it in multiple languages going forward. I guess successfully moving to the Rust version and not having to move back in a month may be the "experiment".

Like Firefox did, Ladybird can pick their spots with regards to which bits to move to Rust. Firefox has a Rust-based CSS parser as I recall. This makes sense for security reasons since it processes untrusted input as a core function. That may be a good place for Ladybird to start as well. Like JavaScript, I am sure it has great test coverage.

Better late than never, but still...

Posted Feb 23, 2026 19:02 UTC (Mon) by roc (subscriber, #30627) [Link] (5 responses)

When you start a greenfield project like this, it's a great opportunity to make good decisions from the start while your legacy competitors are stuck with their legacy decisions. Too bad Ladybird missed that opportunity in the choice of programming language. It would be interesting to know why they're making a different decision now than they made in 2024 --- what's changed? 2024 wasn't that long ago, Firefox had already introduced Rust and Chromium was heading that way. The post doesn't say.

Better late than never, but still...

Posted Feb 23, 2026 19:38 UTC (Mon) by excors (subscriber, #95769) [Link] (3 responses)

In 2024 they said memory safety was important and "In the end it came down to Swift vs Rust, and Swift is strictly better in OO support and C++ interop" (https://xcancel.com/awesomekling/status/1822239138038382684). But Swift support was removed last week ("After making no progress on this for a very long time, let's acknowledge it's not going anywhere and remove it from the codebase" - https://github.com/LadybirdBrowser/ladybird/pull/7999).

I haven't found any explanation of why they think Rust will fare better than Swift did - I guess they're hoping there's more community interest in Rust, or maybe AI tools are better at generating passable Rust than Swift, or something?

Better late than never, but still...

Posted Feb 23, 2026 21:00 UTC (Mon) by jmalcolm (subscriber, #8876) [Link] (2 responses)

Kling has said that Swift cross-platform and C++ interop have not matured as much as he was hoping. That is why no Swift progress was made and why they took another look at Rust.

His commit formalizing the move away from Swift came half-way through the port of LibJS to Rust. I guess he was having enough success to know that Rust was a better candidate than Swift at that point. But even now he is painting Rust as "an experiment" rather than as the definite language of the future.

Better late than never, but still...

Posted Feb 25, 2026 13:05 UTC (Wed) by iabervon (subscriber, #722) [Link] (1 responses)

For that matter, executing Javascript is a less clear fit for OOP than implementing DOM and other things a browser does, while also probably being a good place to get some of the ownership rules that Rust has. It will probably need a bunch of "unsafe" blocks (such as making the assumption that memory with dynamic type tags indicating that it is an array actually is an array), but it's also worth saying where that happens.

So even if Rust is selected as definitely the right implementation language for LibJS, that doesn't mean it's necessarily the right language for the rest of Ladybird.

Better late than never, but still...

Posted Mar 2, 2026 5:50 UTC (Mon) by jmalcolm (subscriber, #8876) [Link]

> It will probably need a bunch of "unsafe" blocks

I only skimmed the Rust code but I was surprised how normal it looked. And I did not really see "unsafe". And the recent commit history makes it seem that they are able to human edit the Rust code without too much trouble.

> that doesn't mean it's necessarily the right language for the rest of Ladybird

Agreed

Better late than never, but still...

Posted Feb 23, 2026 20:54 UTC (Mon) by jmalcolm (subscriber, #8876) [Link]

> make good decisions from the start

We have to properly identify "the start" here. Let's work backwards...

Ladybird forked from the SerenityOS project. At the time of the fork, Ladybird was already complete enough to render many web pages. It was close to being a "complete" browser though being far from finished and it was already 100% written in C++. Inside SerenityOS, the web browser that became Ladybird started as a simple HTML parser/viewer intended to display simple documentation. It was written in C++ because the entirety of SerenityOS was written in C++. The SerenityOS project was created by its founder to be a productive replacement for his personal substance abuse challenges. He created his "happy place" operating system in C++ as it was his favourite programming language at the time.

When Ladybird was forked from SerenityOS, the choice would have been "continue the code base in C++" or "start-over". I doubt the second option was even considered.

That said, the developers have been investigating other language options since long before the fork. Rust was considered and discounted early on as a poor fit for the extensive OOP already in use. They even started to create their own programming language: Jakt.
https://github.com/SerenityOS/jakt

The reason given for moving away from Swift now is that the cross-platform and C++ interop story did not materialize as they had hoped after Swift 6. Rust was the second choice before. That makes it the top choice now. And "AI helped me port our entire JavaScript engine in 2 weeks" probably helped a lot as well. That is decidedly new.