alt Hacker NewsLadybird Browser adopts Rust
Comments
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.
> 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.
> 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.
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.
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
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.
> 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!
Interestingly editorialized title omits “with help from AI”.
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.
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.
> We previously explored Swift, but the C++ interop never quite got there
But Rust doesn't have C++ interop at all?
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.
I hope that this opens the door for collaboration between Ladybird and Servo, no need to reinvent the wheel for core components.
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
> 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).
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 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++.
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.
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).
If this means we will get an independent state-of-the-art browser engine, I'm all for it.
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.
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
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.
Oooh noooo I will have to fork it before it is too late!
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.
> 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.
Great! I can't wait they totally ditch C++
Using LibJS with servo, when?
Good step. It will bring many more contributors.
Something of a culture clash here ain’t it, albeit an imbalanced one.
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!
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.
How long until Ladybird begins to impact market dominance for Chrome and Firefox? My guess: Two years.
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.
Guess it will never come out.
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.
I guess the ETA will pushed back by a few years then?
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.
[dead]
Used a LLM to translate their LibJS to Rust. Wonder why they didn't look into picking up where servo left off.
developers with good taste like Andreas Kling will be able to design entire OSes with coding agents
10x programmers become 100x with the power of AI. Not an unexpected outcome. But the world is going to suck for ordinary people. 10x programmers will gladly embrace this future become it empowers them more.
We have to accept this reality and act accordingly.
Yes you will downvote me. I have accepted this reality and will hack on my own projects in the woods or in a cave, on my own terms.
------ I wrote the following after a bit of thought:
It was with a heavy heart that I learned that the author of "Ladybird Browser" managed to convert the JavaScript compiler from C++ to Rush in 2 weeks, with the help of AI. It was a mix of awe and depression. 10x programmers leveraged AI to achieve a great feat in only 2 weeks, passing all tests. This was not a surprise to me as we all saw the writing on the wall a couple of years ago, but reality hit hard still. I'm a very average programmer, a very average person, and perhaps worse than the median in many perspectives. The gap between an ordinary people, with a 10X whatever, is getting much larger due to the evolution of tools. No, I do not believe AI can ever replace humans completely, at least not in the near future. But the point is, we the ordinary people are getting less and less relevant. The gate of professional work, the gate from which we drink satisfaction by knowing that many are using our work, is closing. I have no ill feeling towards any 10X programmers who is enjoying this. They are much better than me. They have earned it. They deserve it. And I deserve it, too, to have allowed myself to be mediocre. Being mediocre is a lesser evil then and now, but is a major sin in the future.
I soaked myself in "Crypto-zoologist" (Disco Elysium) to savor the moment. It is fine. Perhaps I will never get a professional job as a system programmer, and this is fine. I'll go into the woods, stay in a cave, and hack on my own projects, on my own terms. I do no care about the end products, and neither do I care whether people use them at all. Programming is a ritual to dispel the daemons from my soul, and I must keep doing it, until the last moment.
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.
> 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.