Aggregates

Evidence: High: 0 Medium: 5 Low: 3 No Data: 23

Theme Radar

viktorcode 2026-02-23 11:47 UTC link

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

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

mosura 2026-02-23 11:48 UTC link

Interestingly editorialized title omits “with help from AI”.

qudat 2026-02-23 11:50 UTC link

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

skerit 2026-02-23 11:56 UTC link

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

ramon156 2026-02-23 12:19 UTC link

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.

djoldman 2026-02-23 12:32 UTC link

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.

pjmlp 2026-02-23 12:33 UTC link

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.

easton 2026-02-23 12:48 UTC link

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

account42 2026-02-23 12:51 UTC link

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

nicoburns 2026-02-23 12:59 UTC link

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.

thiht 2026-02-23 13:10 UTC link

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

vipulbhj 2026-02-23 13:18 UTC link

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.

Fervicus 2026-02-23 13:19 UTC link

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

ZoomZoomZoom 2026-02-23 14:10 UTC link

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.

kneel25 2026-02-23 14:34 UTC link

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

alabhyajindal 2026-02-23 15:15 UTC link

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

alabhyajindal 2026-02-23 15:38 UTC link

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

jp1016 2026-02-23 15:57 UTC link

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.

AlexCoventry 2026-02-24 06:39 UTC link

> If you look at the code, you’ll notice it has a strong “translated from C++” vibe. That’s because it is translated from C++. The top priority for this first pass is compatibility with our C++ pipeline. The Rust code intentionally mimics things like the C++ register allocation patterns so that the two compilers produce identical bytecode. Correctness is a close second. 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.

Does this still get you most of the memory-safety benefits of using Rust vs C++?

andsoitis 2026-02-24 13:22 UTC link

> We will continue developing the engine in C++, and porting subsystems to Rust will be a sidetrack that runs for a long time.

So, even though they want the code base to be in Rust, they will continue writing new code in C++ and then translating it to Rust later to remove the C++ they just added.

There must be a really good reason for this, such as Rust doesn’t interop well with C++, otherwise this seems like a poor decision.