Ladybird adopts Rust

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.

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

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.

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

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.

Testing has become 10x as important as ever.

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

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

From their post on Twitter in 2024 when they adopted Swift, with a comment on Rust.

My general thoughts on Rust:

- Excellent for short-lived programs that transform input A to output B

- Clunky for long-lived programs that maintain large complex object graphs

- Really impressive ecosystem

- Toxic community

https://xcancel.com/awesomekling/status/1822241531501162806

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

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

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.

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

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.

They are lost. C & C++ are absolutely fine.

Interestingly editorialized title omits “with help from AI”.

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.

> We previously explored Swift, but the C++ interop never quite got there

But Rust doesn't have C++ interop at all?

The "human-directed, not autonomous" framing is the part people keep glossing over. Claude Code here is a compiler-level translation tool, you are still the architect deciding what gets ported and in what order.

The real question is what this does to migrations that never happened because 18 months of rewrite did not pencil out. A 2-week port fundamentally changes that calculus.

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 really YOLOing as the original author doesn't know Rust well so what happens if they hit some complex production issue LLM aren't aware of? Hiring an expensive consultant to fix that until the next LLM iteration?

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

I hope that this opens the door for collaboration between Ladybird and Servo, no need to reinvent the wheel for core components.

Based on the origins of Rust as a tool for writing the really thorny, defensive parsers of potentially actively hostile code for firefox, I have to imagine that another web browser is the most at-home place the language could ever be.

Is there any discussion on why D or even Ada was not considered? These languages have been around for long time. If they were willing to use llm to break the initial barrier to entry for a new language, then a case can be made for these languages as well.

> We’ve been searching for a memory-safe programming language to replace C++ in Ladybird for a while now.

The article fails to explain why. What problems (besides the obvious) have been found in which "memory-safe languages" can help. Do these problems actually explain the need of adding complexity to a project like this by adding another language?

I guess AI will be involved which, at this early point in the project would make ladybird a lot less interested (at least to me).

This may sound stupid, but I wonder if using GPUI for a web browser could have some performance benefits...

If it is this easy, surely the trend is Rust output being an intermediate pass of the LLM super compiler. A security subset if you will (like other kinds of optimization), it will move from Rust specs to some deeper level of analysis and output the final executable. Some brave souls will read the intermediate Rust output (just like people used to read the assembler output from compilers) but the LLM super compiler will just translate a detailed English like spec into final executables.

If this means we will get an independent state-of-the-art browser engine, I'm all for it.

My intuition is that they will convert to zig again when it stables. If it is possible to do it using LLM in 2 weeks for rust, then it would be the same for zig, too.

While rust is nice on paper, writting complex software in it is mentally consuming. You can not do it for a long time.

Any word on how much more memory safe the implementation is? If passing a previous test suite is the criteria for success, what has changed, really? Are there previous memory safety tests that went from failing to passing?

I am very interested to know if this time and energy spent actually improved memory safety.

Other engineers facing the same challenges want to know!

I'm still glad that NetSurf exists.

Interesting in context of that some time ago Andreas said that they failed on porting TypeScript compiler from TypeScript itself to Go lang by using LLMs and they went with manual port https://youtu.be/uMqx8NNT4xY?si=Vf1PyNkg3t6tmiPp&t=1423

Good step. It will bring many more contributors.

That's a pivot, iirc they wanted to swift (I'm very glad they didn't do that). It's cool to see something like claude be useful for large scale projects like that

Using LibJS with servo, when?

I wonder what is gained by this port though, if the C++ codebase already employed modern approaches to memory management. It's entirely possible that the Rust version will perform worse too as compilers are less mature.

Fuck me. This is wild. Sorry for the potty mouth.

    > Porting LibJS
    > Our first target was LibJS , Ladybird’s JavaScript engine. The lexer, parser, AST, and bytecode generator are relatively self-contained and have extensive test coverage through test262, which made them a natural starting point.

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

I'm not here to troll the LLM-as-programmer haters, but Ladybird (and Rust!) is loved by HN, and this is a big win.

How long until Ladybird begins to impact market dominance for Chrome and Firefox? My guess: Two years.

Were there any immediate benefits of this conversion, e.g. reduced memory use or lower CPU utilization?

I must admit to being somewhat confused by the article's claim that Rust and C++ emit bytecode. To my knowledge, neither do (unless they're both targeting WASM?) - is there something I'm missing or is the author just using the wrong words?

EDIT: bramhaag pointed out the error of my ways. Thanks bramhaag!

Something of a culture clash here ain’t it, albeit an imbalanced one.

I don't get it, and I don't have a dog in the C/C++ vs. Rust race. Ladybird has ~1200 contributors with a predominance of C++ contributions, followed by HTML, and with "other" lying at 0.5%.

That's a lot of people contributing.

How many of them will be less willing to contribute in the future, and less productive when they do if a sizable portion is in Rust? Maybe there'll be more contributions and maybe there'll be less. I don't know. If you've managed to develop a community of 1200 developers who are willing to advance the project why upset the applecart?

This is sort of hilarious if you think about it. The Firefox browser is completely written in Rust. Now Ladybird is a "human-directed ai" Rust browser. Makes you wonder how much of the code the two browsers will share going forward given llm assisted autocompletes will pull from the same Rust Browser dataset.

Oooh noooo I will have to fork it before it is too late!

This will be another bad decision just like with Swift. From what I heard, Rust is notoriously bad at letting people define their own structure and instead beats you up until you satisfy the borrow checker. I think it'll make development slow and unpleasant. There are people out there who enjoy that, but it's not a fit for when you need to deliver a really huge codebase in reasonable time. I remember Andreas mentioning he just wanted something like C++, but with a GC and D would be absolutely perfect for this job.

Someone will be put down like a dog.

Great! I can't wait they totally ditch C++

I guess the ETA will pushed back by a few years then?

What are Rust programmers to do now that LLMs can port code to Rust??

Guess it will never come out.

I wouldn't mind if one result of this was a writeup on what patterns/antipatterns are there when converting code and concepts that used to be very aligned with C++-style OOP, deep inheritance and all that jazz, to what feels natural in Rust, and how you can rephrase those concepts without loss in the substance of what you need to do.

I guess it's a long way off, since the LLM translation would need to be refactored into natural Rust first. But the value of it would be in that it's a real world project, and not a hypothetical "well, you could probably just...".

Sigh agents keep killing all the passion I have for programming. It can do things way faster than me, and better than me in some cases. Soon it will do everything better and faster than me.

I am unsure if I can rationally justify saying this, but I am left with disappointment and unease. Comparable to when a series I care about changes showrunner and jumps the shark.

I feel similar about the potential of this technique and have heard this from other C++ developers too.

Rust syntax is a PITA and investing a lot of effort in the language doesn’t seem worth the trouble for an experienced C++ developer, but with AI learning, porting and maintenance all become more accessible. It’s possible to integrate Rust in an existing codebase or write subparts of larger C++ projects in Rust where it makes sense.

I was recently involved in an AI porting effort, but using different languages and the results were fine. Validating and reviewing the code took longer than writing it.

Chatbot-translated code which is C++ foisted onto Rust? I will respectfully roll my eyes.

Ah, but I see they actually haven't done that to most of their code, so maybe it's just a bit of pandering to the hype and fashion.

i rememebr seeing interviews saying rust is not suited for this project because of recursion and dom tree. how they tested multiple languages and settled on swift. then they abandon swift and now they shift towards rust.

this entire project starts to look like "how am i feeling today?" rather than a serious project.

Some time ago I was perma-banned from the Ladybird github repository. One can say it is warranted, or not (people have their own opinion; I completely disagree with their decision). Now that this has happened, I can speak more freely about Ladybird.

Naturally this will be somewhat critical, but I need to first put things into context. I do believe that we really need an alternative to Google dominating our digital life. So I don't object that we need alternatives; whether Ladybird will be an alternative, or not, will be shown in the future. Most assuredly we need competition as otherwise the Google empire moves forward like Darth Vader and the empire (but nowhere near as cool as that; I find Google boring and lame. Even skynet in Terminator was more fun than Google. Google just annoys the heck out of me, but back to the topic of browsers).

So with that out of the way ... Ladybird is kind of ... erratic.

Some time ago, perhaps two months or three, Andreas suddenly announced "Swift WILL BE THE FOREVER FUTURE! C++ sucks!!!". People back then were scratching heads. It was not clear why Swift is suddenly our saviour.

Ok, now we learn - "wait ... swift is NOT the future, but RUST is!!!". Ok ... more head-scratching. We are having a deja-vu moment here... but it gets stranger:

"We previously explored Swift, but the C++ interop never quite got there, and platform support outside the Apple ecosystem was limited. Rust is a different story."

and then:

"I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation"

So ... the expertise will be with regards to ... relying on AI to autogenerate code in ... Rust.

I am not saying this is a 100% fail strategy, mind you. AI can generate useful code, we could see that. But I am beginning to have more and more doubts about the Ladybird project. Add to this the breakage of URLs that are used by thousands or million people world-wide (see the issues reported on the github tracker); or also the fact that, once you scale-up and more and more people use ladybird, will you be able to keep up with issue trackers? Will you ban more people?

In a way it is actually good that I am no longer allowed to make comments on their repository because I can now be a lot more critical and ask questions that the ladybird team will have to evaluate. Will ladybird blend? Will it succeed? Will it fail? Yes, it is way too early to make an evaluation, so we should evaluate in some months or so, perhaps end of this year. But I am pretty certain the criticism will increase, at the least the moment they decide to leave beta (or alpha or whatever model they use; they claimd they want a first working version in this year for Linux users, let's see whether that works).

[dead]

[dead]

[dead]

[flagged]

[flagged]

Completely ignoring the Rust aspect, I’m disappointed that two weeks were spent on something that isn’t getting Ladybird to a state where it can be used as a daily driver. Ladybird isn’t usable right now, and if it was usable, improving the memory safety would be a commendable goal. Right now I just feel like this is premature.

ÄNTLIGEN!

developers with good taste like Andreas Kling will be able to design entire OSes with coding agents

Cool project, but I'm a bit curious hearing how the rest of the project feels about this?

I'm not sure how I'd feel if I woke up and found a system I worked on had been translated into an another language I'm not neccessarily familiar with. And I'm not sure I'd want to fix an non-idiomatic "mess" just because it's been translated into a language I'm familiar with either (although I suspect they'll have no problem attracting rust developers).