> 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.
> 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.
> 10/10 - would generate tens of thousands of lines of useless code again.
Me too! A couple days ago I gave claude the JMAP spec and asked it to write a JMAP based webmail client in rust from scratch. And it did! It burned a mountain of tokens, and its got more than a few bugs. But now I've got my very own email client, powered by the stalwart email server. The rust code compiles into a 2mb wasm bundle that does everything client side. Its somehow insanely fast. Honestly, its the fastest email client I've ever used by far. Everything feels instant.
I don't need my own email client, but I have one now. So unnecessary, and yet strangely fun.
Its quite a testament to JMAP that you can feed the RFC into claude and get a janky client out. I wonder what semi-useless junk I should get it to make next? I bet it wouldn't do as good a job with IMAP, but maybe if I let it use an IMAP library someone's already made? Might be worth a try!
Same here. I had Claude write me a web based RSS feed reader in Rust. It has some minor glitches I still need to iron out, but it works great, is fast as can be, and is easy on the eyes.
Haha glad to see someone else did something like this. A couple weeks ago I asked Claude to recommend a service that would allow me to easily view a local .xml file as an RSS feed. It instead built a .html RSS viewer.
Rust is the final language.
Defect free. Immaculate types. Safe. Ergonomic. Beautiful to read.
AI is going to be writing a lot of Rust.
The final arguments of "rust is hard to write" are going to quiet down. This makes it even more accessible.
> Beautiful to read.
Oh my, there's a new language called Rust? Didn't they know there already is one? The old one is so popular that I can't imagine the nicely readable one to gain any traction whatsoever (even if the old one is an assault on the senses).
> Rust is the final language.
I honestly can't tell if this is a humorous attack or not.
Poe's law is validated once again.
It's honest. If we can serialize our ideas to any language for durability, Rust is the way to go.
It's not the best tool for the job for a lot of things, but if the LLMs make writing it as fast as anything else - whelp, I can't see any reason not to do it in Rust.
If you get any language outputs "for free", Rust is the way to go.
I've been using Claude to go ridiculously fast in Rust recently. In the pre-LLM years I wrote a lot of Rust, but it definitely was a slow to author language. Claude helps me produce it as fast as I can think. I spend most of my time reviewing the code and making small fixes and refactors. It's great.
I'll just stick with C as my lingua franca, and won't be involving Microsoft in my programming life, thanks.
Why not go full functional programming at that point? If the main issue with FP has been accessibility, then it should really take off now.
When you do fully value-oriented programming in Rust (i.e. no interior mutability involved) that's essentially functional programming. There's mutable, ephemeral data involved, but it's always confined to a single well-defined context and never escapes from it. You can even have most of your code base be sans-IO, which is the exact same pattern you'd use in Haskell.
Needs monads (not joking)
"There is no such things as Rust evangelism, what are you even talking about? Are these Rust fanboys in room with us?"
Please post this. I'd love to play with it and, especially, see how fast it is.
> a relic from the days when everyone thought Drupal was the future (long time ago).
Drupal is the future. I never really used it properly, but if you fully buy into Drupal, it can do most everything without programming, and you can write plugins (extensions? whatever they're called...) to do the few things that do need programming.
> 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.
This is the problem! Fickle halfwits mindlessly buying into whatever "next big thing" is currently fashionable. They shoulda just learned Drupal...
I'm not sure if you're serious or not, but while I never liked Drupal (even used to hate it once upon a time), I always liked the pragmatism surrounding it, reaching to the point of saving php code into the mysql database and executing from there.
> It burned through a mountain of tokens, but 10/10 - would generate tens of thousands of lines of useless code again.
This is the biggest bottleneck at this point. I'm looking forward to RAM production increasing, and getting to a point where every high-end PC (workstation & gaming) has a dedicated NPU next to the GPU. You'll be able to do this kind of stuff as much as you want, using any local model you want. Run a ralph loop continuously for 72 hours? No problem.
There are plenty of SMEs trapped into that future. :)
> It burned through a mountain of tokens, but 10/10 - would generate tens of thousands of lines of useless code again.
Pardon me, and, yes, I know we're on HN, but I guess you're... rich? I imagine a single run like this probably burns through tens or hundreds of dollars. For a joke, basically.
I guess I understand why some people really like AI :-)
It was below 100$, but only after burning through the 20x max session limit.
The subsidized Codex/Claude subscriptions make it not so bad.
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.
Is it any surprise that the cocaine cartels really want you to buy more cocaine, so they don't focus on its usefulness in pain relief and they refine it and cut it with the cheapest substances that will work rather than medical-grade reagents?
Same thing.
It's surprising that the ones who are producing the cocaine, don't try to find the best use of the cocaine, yes. But then these are VC-fueled businesses, then it all goes out the window, unfortunately. Otherwise they'd actually focus on usefulness, not just "usage" or whatever KPI they go by and share with their investors.
>Agree, and it's also such a shame that none of the AI companies actually focus on that way of using AI.
This is because, regardless of the current state of things, the endgame which will justify all the upfront investment is autonomous, self-improving, self-maintaining systems.
Of course there are tools focusing on this. It takes a little getting used to how prevalent it is. My editor now can anticipate the next three lines of code I intend to write complete with what values I want to feed to the function I was about to invoke. It all shows up in an autocomplete annotation for me. I just type the first two or three characters and press tab to get everything exactly how I was about to type it in--including an accurate comment worded exactly in my voice.
Is that what you mean by IA?
For example, I type "for" and my editor guesses I want to iterate over the list that is the second argument of the function for which I am currently building the body. So it offers to complete the rest of the loop condition for me. Not only did it anticipate that I am writing a for loop. It figures out what I want to iterate over, and perhaps even that I want to enumerate the iteration so I have the index and the value. Imagine if I had written a comment to explain my intent for the function before I started writing the function body. How much better could it augment my intellect?
To be honest, I'm not quite sure what the ideal UX looks like yet. The AI assisted autocomplete is too little, but the idea of saying "Build X for purpose Y" is too high-level. Maintaining Markdown documents that the AI implements, also feels too high-level, but letting the human fully drive the implementation probably again too low-level.
I'm guessing the direction I'd prefer, would be tooling built to accept and be driven by humans, but allowed to be extended/corrected by AI, or something like that, maybe.
Maybe a slight contradiction, and very wish-washy/hand-wavey, but I haven't personally quite figured out what I think would be best yet either, what the right level actually is, so probably the best I could say right now :) Sorry!
The Markdown documents can be at any level. Just keep asking the AI to break each individual step in the plan down into substeps, then ask it to implement after you review. It's great for the opposite flow too - reverse engineering from working legacy code into mid-level and high-level designs, then proposing good refactors.
I think it was Steve Jobs who said computers should be like a bicycle for the mind, I tend to agree
Yeah, Douglas Engelbart was also a huge believer in that, and I think from various stuff I've read from him and the Augmentation Research Center put me on this track of really agreeing with it.
"Bicycle for the mind", as always when it involves Jobs, sounds more fitting for the masses though, so thanks for sharing that :)
> Agree, and it's also such a shame that none of the AI companies actually focus on that way of using AI.
their valuations are replaced on getting rid of you entirely, along with everyone else
the "humans can use it to increase their productivity" is an interim step
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".
This is also how some of us use Claude despite what the haters say. You dont just go “build thing” you architect, review, refine, test and build.
It's how most of us are actually going to end up using AI agents for the foreseeable future, perhaps with increasing degrees of abstraction as we move to a teams-of-agents model.
The industry hasn't come up with a simple meme-format term to explain this workflow pattern yet, so people aren't excited about it. But don't worry, we'll surely have a bullshit term for it soon, and managers everywhere will be excited. In the meantime, we can just continue doing work with these new tools.
This is an opportunity to select some stupid words that you would like to hear repeated a million times. The process is like patiently nurturing a well-contained thing, so how about "egg coding"?
I havent quite dealt with "teams of agents" yet outside of Claude Code itself spawning subagents, but I have some ideas as to how to achieve it in a meaningful way without giving a developer 10 claude code licenses, I think the real approach that makes more sense to me is to still have humans in the loop, but have their respective agents sync together and divide work towards one goal, but being able to determine which tasks are left to be worked one and tested. I do think for the foreseeable future you will need human validation for AI.
https://youtu.be/JV-wY5pxXLo?si=ga-9Gg8IZfU6g8Tg
It's vibe engineering
I'm not sure there's going to be a term, because there's no difference from normal, good quality engineering. You iterate on design, validate results, prioritise execution. It's just that you hand over the writing code part. It's as boring as it gets.
I thought the term was "agentic engineering"
I like "spec driven development" but I honestly don't care what you call it, just let me build things and leave me alone. :)
SDD is more like a subset. There are different ways to manage context in agentic engineering
Yeah that's the top contender at the moment. I think it's pretty good.
> how some of us
Operative word being “some”. The issue is that too many aren’t doing it that way.
> You dont just go “build thing”
Tell that to the overwhelming majority of posters discussing vibe coding, including on HN.
Sure, but they're going to be stuck writing software for yesterday's problems. As our tools become more powerful, we're going to unlock new problems and expectations that would be impossible or impractical to solve with yesterday's tooling.
>Sure, but they're going to be stuck writing software for yesterday's problems
As long as they get paid for it (or have fun, if it's a personal project), they couldn't care less about that. Tomorrow's problems are overrated.
I suppose to some extent those people have always existed. The ones who would choose the most expedient solution.
The difference now is they can get much further along.
> despite what the haters say
Thinking people who disagree with you hate you or hate the thing you like is a recipe for disaster. It's much better to not love or hate things like this, and instead just observe and come to useful, outcome-based conclusions.
Look at any HN thread that has a project that uses AI in any way, shape or form. People quickly remark that it is slop, without even reviewing the code. If that's not blind hatred of AI, I don't know what is.
There's a huge distinction between Vibe Coding, and actual software engineers using AI tooling effectively. I vibe code for fun sometimes too, nothing wrong with it, helps me figure out how the model behaves in some instances, and to push the limits of what I understand.
Vibe Coding is like porn for programmers. It probably isn't good for you, and you'd probably be better off actually doing the thing yourself, but it feels good and satisfies our desires for instant gratification
Well, take for example, I have ideas I've had for years but no time for because by now the requirements are insane. I want to build a backend that could survive nuclear fallout type stuff. I braindump to Claude, watch it churn out my vision for the last 12 years, its insane.
There's other things too though: my ADD and my impostor syndrome don't matter to Claude, Claude just takes it all in, so as I keep brain dumping, it keeps chugging along. I don't have to worry a bout "can I really do this?" it just does it and I can focus on "what can I do to make it better" essentially.
For me it's beyond "porn coding" its basically fulfilling my vision that's been locked away for years but I've had no time to sit down and do it fully. I can tell Claude to do something, my kid comes up and asks me to go draw with them and I can actually just walk away and look at the output and refine.
LLMs really do attract haters in the classic sense though. You'll find them in almost every thread on here.
They also attract grifters, frauds, conmen, snake oil peddlers, and every stripe of bullshit artist. I'm someone you probably would view as a hater, but I truly don't hate LLMs. I hate the lies. Projects like this are interesting, I wish there was a lot more of this and a lot less of the "trust me bro" stuff.
I had a script in another language. It was node, took up >200MB of RAM that I wanted back. "claude, rewrite this in rust". 192MB of memory returned to me.
Solving the big RAM shortage one prompt at a time.
> This was human-directed, not autonomous code generation.
All my vibe coded projects are human directed, unless explicitly stated otherwise
Coding assistants are great at pattern matching and pattern following. This is why it’s a good idea to point them at any examples or demos that come with the libraries you want to use, too.
I am having immense success with the latest models developing a personal project that I open sourced and then got burned off by.I can't write anymore by hands but I do enjoy writing prompts with my voice.I have been shipping the best code the project has ever seen.The revolution is real.
Quite good. I ported my codebase from Go to Rust in a fraction of the time it would have taken me to rewrite it.
> 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.
It doesn't have to all-or-nothing. Firefox has been a mixed C++ and Rust codebase for years now. It isn't like the code is written twice. The C++ components are written in C++, and the Rust components are written in Rust.
I suspect that'll also be what happens here. And if the use of Rust is successful, then over time more components may switch over to Rust. But each component will only ever be in one language at a time.
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.
> I guess more anti-hype, where Rust was the hype
Yeah that is the thing I struggle with. I am really happy for people falling in love with Rust. It is a amazing language when used for the right use case.
The problem is that had my Rust adventures a few years ago and I am over the hype cycle and able to see both the advantages and disadvantages. Plus being generally older and hopefully wiser I don't tie my identity towards any specific programming language that much.
So sometimes when some Junior dev discovers Rust and they get really obnoxious with their evangelicalism it can be very off putting. Really not sure how to solve it. It is good when people get excited about a language. It just can be very annoying for everyone else sometimes.
I guess I missed this, thanks!
I'd argue Ladybird itself is a "hype" project.
Anything trying to break the browser monopolies in a meaningful way deserves the hype, IMO.
Fair point. What does Ladybird need to achieve in your opinion to shake the "hype" label? Honestly, I, myself, don't have a good answer!
> What does Ladybird need to achieve in your opinion to shake the "hype" label?
A release (?)
To me, a project's "hype-ness" is the ratio between how much attention it gets and how useful it actually is to users.
As a browser, Ladybird usefulness is currently quite limited for obvious reasons. This is not meant to dismiss its achievements, nor to overlook the fact that building a truly useful browser for everyday users is something few open source teams can accomplish without the backing of a billion dollar company. Still, in its present state, its practical utility remains limited.
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.
Ladybird as a project is not that old, and it's still in pre-alpha, if they are going to make important changes then it's better now than later.
There's been some fun volatility with the author over the years. I told him once that he might want to consider another language to which he replied slightly insultingly. Then he tried to write another language. Then he tried to switch from C++ to Swift, and now to Rust :P
Upside: he's learning?
They abandoned Swift recently.
The public announcement was less then a week ago. Meanwhile in TFA:
> ... the entire port took about two weeks.
So he was ~halfway in when he made the Swift announcement.
Doesn’t sound like a bad thing to evaluate the most obvious alternative to build confidence before officially pulling the plug.
TFA mentions "the contributor's" stance on Swift.
But not the stance on Rust, which is something I'm wondering. I understand there's a core team assigned, but are the ~200 contributors okay with this migration?
Why would 200 contributors have to be okay with this migration? The project has a leader, the leader makes decisions.
because let's say 150 contributors might not be okay with the decision and leave. hard to lead from the front if there is nobody behind to be lead.
> 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.
Your argument is just as applicable on human code reviewers. Obviously having others review the code will catch issues you would never have thought of. This includes agents as well.
They’re not equal. Humans are capable of actually understanding and looking ahead at consequences of decisions made, whereas an LLM can’t. One is a review, one is mimicking the result of a hypothetical review without any of the actual reasoning. (And prompting itself in a loop is not real reasoning)
With humans though, I wouldn't have to review 20k lines of code at once.
So ask the AI to just translate one little chunk at a time, right?
>Your argument is just as applicable on human code reviewers.
The tests many of us use for how capable a model or harness is is usually based around whether they can spot logical errors readily visible to humans.
That is what the testing suite is there to check, no?
No. Testing generally can only falsify, not verify. It’s complementary to code review, not a substitute for it.
You mean the testing suite generated by AI?
Yeah, I lost all interest in the ladybird project now that it is AI slop.
No one wants to work with this generated, ugly, unidiomatic ball of Rust. Other than other people using AI. So you dependency AI grows and grows. It is a vicious trap.
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.
Eh, he's given an interview where he talks about the Swift decision. He and several maintainers tried building some features in Swift, Rust, and C++, spending about two weeks on each one IIRC. And all the maintainers liked the experience of Swift better. That might have ended up wrong, but it's a pretty reasonable way to make a decision.
> but all of this makes me slightly wary.
Wary of what?
I'd say it's the idea/fact/feeling that, in 2026, agency matters more than skill/wisdom/intelligence.
Long read on the topic (quite funny, covers Cluely): https://harpers.org/archive/2026/03/childs-play-sam-kriss-ai...
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.
For a personal thing I had AI write some python libraries to power a cli. It has to do with simple excel file filtering, grouping and aggregating. Nothing too fancy. However since it's backed by a library, I am playing with different UIs for the same thing and it's fun to say.. Do it with streamlit. Oh it can't do this particular thing. Fine do it with shiny. No? OK Dash. It takes only like an hour to prototype with a whole new UI library then I get to say "nah" like a spoiled child. :)
Well, I am on the provocative side that as AI tooling matures current programming languages will slowly become irrelevant.
I am already using low code tooling with agents for some projects, in iPaaS products.
> Well, I am on the provocative side that as AI tooling matures current programming languages will slowly become irrelevant.
I have the opposite opinion. As LLM become ubiquitous and code generation becomes cheap, the choice of language becomes more important.
The problem with LLM for me is that it is now possible to write anything using only assembly. While technically possible, who can possibly read and understand the mountain of code that it is going to generate?
I use LLM at work in Python. It can, and will, easily use hacks upon hacks to get around things.
Thus I maintain that as code generation is cheap, it is more important to constraint that code generation.
All of this assume that you care even a tiny bit about what is happening in your code. If you don't, I suppose you can keep banging the LLM to fix that binary blob for you.
> The problem with LLM for me is that it is now possible to write anything using only assembly. While technically possible, who can possibly read and understand the mountain of code that it is going to generate?
As a very practical problem the assembly would consume the context window like no other. And another is having some static guardrails; sometimes LLMs make mistakes, and without guard rails it debugging some of them becomes quite a big workload.
So to keep things efficient, an LLM would first need to create its own programming language. I think we'll actually see some proposals for a token-effective language that has good abstraction abilities for this exact use.
Lets say years of offshoring projects have helped to reach that opinion.
I don't agree. For one thing, the language directly impacts things like iteration speed, runtime performance, and portability. For another, there's a trade-off between "verbose, eats context" and "implicit, hard to reason about".
IMO Rust will strike a very strong balance here for LLMs.
Formal specifications and automated testing, will beat any language specific tooling.
Hardly much different than dealing with traditional offshoring projects output.
What is a programming language used for if not the most formal specification possible? Of course it doesn't matter what language you use if you perfectly describe the behavior of the program. Of course, there's also no point in using LLMs (or outsourcing!) at that point.
If the offshore company provides me a Rust crate that compiles, that is already a lot of guarantee. Now that does not solve the logic issues and you still need testing.
But testing in Python is so easy to abuse as LLM. It will create mocks upon mocks of classes and dynamically patch functions to get things going. Its hell to review.
Im already using models to reason about and summarize part of the code from programming language to prose. They are good at that. I can see the process being something like english to machine lang, machine lang to english if the human needs to understand. However amother truism is that compilers are a great guardrail against bad generated code. More deterministic guardrails are good for llms. So yeah im not there yet where i trust binaries to the statistical text generators.
> 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 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.
Spending weeks porting (presumably) working code with LLM is a bit strange
that's only the mechanical translation too
the hard bit (borrow checker) has still to be done...
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.
I’ve been part of at least 2 successful rewrites. I think that Joel’s post is too often taken as gospel. Sometimes a rewrite is the best way forward.
Moving Ladybird from C++ to a safer more modern language is a real differentiator vs other browsers, and will probably pay dividends. Doing it now is better than doing it once ladybird is fully established.
One last point about rewrites: you can look at any industry disruptor as essentially a team that did a from-scratch rewrite of their competitors and won because the rewrite was better.
> I’ve been part of at least 2 successful rewrites. I think that Joel’s post is too often taken as gospel. Sometimes a rewrite is the best way forward.
I can recall recently, listening to an Oxide and Friends podcast where they spent 30 minutes dumping all over "Agile Dev", only to have a very senior, hands-on guy join from AWS and absolutely deliver the smack down. (Personally, I have no positive experiences with Agile Dev, but this guy really stunned the room into silence.) The best part: The Oxide crew immediately recognized the positive experence and backed off the give this guy the space he needed to tell and interesting story. (Hats off the Ox crew for doing that... even if I, personally, have zero love for Agile Dev.)
Firefox, Opera and first Edge were rewrites.
I still don’t buy this “safer more modern” mentality. Modern C++ pretty much solves the safety issues. People need to learn how to use tools properly.
If you ask me, Go is a better Rust. Rust is an ugly version of C++ with longer compile times and a band of zealous missionaries.
I mean the keywords mut and fn very annoying to read just get rid of them or spell the f*n thing function.
> Modern C++ pretty much solves the safety issues.
The statistics from projects that have adopted Rust and measured the effect say otherwise. See https://security.googleblog.com/2025/11/rust-in-android-move... for example.
> Modern C++ pretty much solves the safety issues.
I always wonder how can one come to such a conclusion. Modern C++ has no way to enforce relationship between two objects in memory and the shared xor mutable rule, which means it can't even do the basic checks that are the foundation of Rust's safety features.
Of course, this statement is also trivially debunked by the reality of any major C++ program with complexity and attack surface of something like a browser. Modern C++ certainly didn't save Chrome from CVEs. They ban a bunch of C++ features, enforce the rule of two, and do a bunch of hardening and fuzzing on top of it and they still don't get spared from safety issues.
FWIW Chrome includes third party libraries like freetype and lots of bugs are in javascript. I imagine defensive checks in javascript will be controversial since performance of javascript is controlled by webdev, not by browser.
Yeah sure. Thing is, C does just fine people are making “safe” ways to run libc. Rust is a complicated monstrosity with a bunch of “unsafe” sprinkles.
What does the memory safety even matter when hackers poison heavily used crates?
This is a very shallow, very boring criticism. I doubt it will resonate. Modern C++ does not solve the safety issues, it has plenty of brand new footguns like string_view. Who cares if Go is better than Rust? Feel free to write Go, no one cares.
"mut and fn very annoying to read" like okay lol who cares? What should anyone take from your post other than that you aren't that into Rust?
> Modern C++ pretty much solves the safety issues
The data says otherwise, three overflows and two UAFs this month in Chrome alone: https://www.cvedetails.com/vulnerability-list/vendor_id-1224...
> Go is a better Rust. Rust is an ugly version of C++ with longer compile times and a band of zealous missionaries.
Eh. There's a lot I like about Go. I adore its compilation speed and the focus on language simplicity. But its got plenty of drawbacks too. Default nullability is a huge mistake. And result types (zig, swift, rust) are way better than go's error handling. Sum types in general are missing from Go, and once you start using them its so hard to go back. Go also doesn't have anywhere near as good interop with native code. Mixing C (or any other LLVM langauge) with rust is easy and feels great. You even get LTO across the language barrier.
The big thing I'm growing to dislike about rust is how many transitive dependencies a lot of projects end up pulling in. Its very easy to end up with projects that take a million years to compile & produce huge binaries. Not because they do a lot but simply because everything depends on everything, and the dependency tree takes a long time to bottom out. I don't know what the right answer is. It feels more like a cultural problem than a language / ecosystem problem. But I wish rust projects felt as lightweight and small as most C projects I've worked with. I'm doing some work with the stalwart email server at the moment (written in rust). Stalwart is a relatively new, well written email server. But it somehow pulls in 893 transitive dependencies! I'm not even joking. Compiling stalwart takes about 20 minutes, and the compilation process generates several gigabytes of intermediate build assets. What a mess.
> Compiling stalwart takes about 20 minutes
20 minutes! What hardware is this on? I've worked on Rust projects with similar numbers of dependencies where the compile time (for a clean release build) was 2-4 minutes (on a MacBook M1 Pro)
> Sum types in general are missing from Go
Not quite. It doesn't have tagged unions, which is what I expect you are thinking of, but it does have sum types.
> People need to learn how to use tools properly.
Nearly 26 years ago! https://www.joelonsoftware.com/2000/04/06/things-you-should-...
What's different today really is the LLMs and coding agents. The reason to never rewrite in another language is that it requires you to stop everything else for months or even years. Stopping for two weeks is a lot less likely to kill your project.
He's still right if you don't have good automated testing and you lost most of the original developers (or you don't have other seniors ceva familiar with the domain).
> then these two teams are essentially in a race against each other and the port will likely never catch up
Ladybird appears to have the discipline to have recognized this: “[Rust] 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.”
And I might suggest that there's the possibility that the C++ code could end up being more cleanly ported to a memory-safe subset of C++. plug: https://github.com/duneroadrunner/scpptool/blob/master/appro...
> A startup switching languages after years of development is usually a big red flag.
Startups are not a good comparison here. They have a different relationship with code than software projects.
Linux has rewriten entire stacks over and over again.
The PHP engine was rewritten completely at least twice.
The musl libc had entire components rewritten basically from scratch and later integrated.
Exactly my thought! I guess I'll keep Firefox for the foreseeable future...
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.
Interestingly editorialized title omits “with help from AI”.
That’s probably just the classic HackerNews title shortening algorithm at work.
> classic HackerNews title shortening algorithm
It's been confirmed by @dang many times before. I'm not sure if that's what cut the title here but I've seen it many times in the last 10 years.
I've seen it happen a couple times, iirc, it removes things after commas, and removes certain words as well
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.
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
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.
Maybe it is my cynicism, but I always suspect such projects to be endless rabbit chasing. It is not about catching it.
Javascript is a self contained sub system, if the public API stays the same, then they can rewrite as much as they want, also I suppose this engine now will attract new contributors that will want to contribute to Ladybird just because they enjoy working with Rust.
Don't forget that the Rust ecosystem around browsers is growing, Firefox already uses it for their CSS engine[0], AFAIK Chrome JPEG XL implementation is written in Rust.
So I don't see how this could be seen as a negative move, I don't think sharing libraries in C++ is as easy as in Rust.
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.
Yet, they are open to further rewrites.
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.
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.
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.
> Ralph Wiggum loop
> We previously explored Swift, but the C++ interop never quite got there
But Rust doesn't have C++ interop at all?
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)
> You can do it via the C ABI, and use opaque pointers to represent higher-level Rust/C++ concepts
Yeah but, you can do the same in Swift
My understanding from a brief read of the Swift issue is that they kept running into bugs in the Swift compiler which, in practice, prevented them from doing the things that they ought to be do in theory. This went on for long enough, that they got fed up and abandoned Swift.
The Rust compiler is incredibly solid (across all target platforms), and while it's C/C++ interop is relatively simplistic, what does exist is extensively battle tested in production codebases.
>But Rust doesn't have C++ interop at all?
It also doesn't have the disadvantages of Swift. Once the promise of Swift/C++ interop is gone there isn't enough left to recommend it.
I’m curious what issues people were running into with Swift’s built in C++ interop? I haven’t had the chance to use it myself, but it seemed reasonable to me at a surface level.
There's a list of unsolved problems in this Ladybird issue, now closed because they dropped Swift: https://github.com/LadybirdBrowser/ladybird/issues/933
for example: "Swift fails to import clang modules with #include <math.h> with libstdc++-15 installed. Workaround: None (!!)"
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.
[1]: https://www.swift.org/documentation/cxx-interop/
[2]: https://www.swift.org/blog/improving-usability-of-c-librarie...
Rust has cxx which I would argue is "good enough" for most use cases. At least all C++ use cases I have. Not perfect, but pretty damn reasonable.
It may have in the future. Crubit is one effort in this direction: https://crubit.rs/
There is also cxx.rs, which is quite nice, albeit you have to struggle sending `std` types back and forth a bit
> albeit you have to struggle sending `std` types back and forth a bit
Firefox solves this partly by not using `std` types.
For example, https://github.com/mozilla/thin-vec exists in large part because it's compatible with Firefox's existing C++ Vec/Array implementation (with the bonus that it's only 8 bytes on the stack compared to 24 for the std Vec).
Luckily, ladybird also does not use `std` types
It's technically Rust -> C -> C++ as it stands right now
I hope that this opens the door for collaboration between Ladybird and Servo, no need to reinvent the wheel for core components.
I thought the entire point of Ladybird was precisely to reinvent the wheel?
Unfortunately licence incompatibility may prevent that. Ladybird is BSD and Servo is MPL. This is also why there is only limited collaboration between Servo and the Rust GUI ecosystem.
Commenting about not reinventing the wheel on a Ladybird post is ironic
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
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++.
the tech debt risk in this case is mostly in the cleanup phase, not the port itself. non-idiomatic Rust that came from C++ tends to have a lot of raw pointer patterns and manual lifetime management that works fine but hides implicit ownership assumptions. when you go to make it idiomatic, the borrow checker forces those assumptions to be explicit, and sometimes you discover the original structure doesn't compose well with Rust's aliasing rules. servo went through this. the upside is you catch real latent bugs in the process.
It depends. I migrated a 20k loc c++ project to rust via AI recently and I would say it did so pretty well. There is no unsafe or raw pointer usage. It did add Rc<RefCell in a bunch of places to make things happy, but that ultimately caught some real bugs in the original code. Refactoring it to avoid shared memory (and the need for Rc<RefCell<>> wasn't very difficult, but keeping the code structure identical at first allowed us to continue to work on the c++ code while the rust port was ongoing and keep the rust port aligned without needing to implement the features twice.
I would say modern c++ written by someone already familiar with rust will probably be structured in a way that's extremely easy to port because you end up modeling the borrow checker in your brain.
Yes, I just translated a Rust library from non-idiomatic and unsafe Rust to idiomatic and safe Rust and it was as much work as if I had rewritten it from scratch.
This is what I was trying to highlight in my post.
I don't think they were having problems with C++, they moved to Rust for memory safety. Mind that they migrated LibJS, their JavaScript library.
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?
> 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).
> What problems (besides the obvious) have been found in which "memory-safe languages" can help.
Why isn't that enough?
Browsers are incredibly security-sensitive projects. Downloading untrusted code from the internet and executing is part of their intended functionality! If memory safety is needed anywhere it's in browsers.
> besides the obvious
Well, what else is there besides the obvious? It's a browser.
Even Chrome has started to adopt Rust due to recurring memory vulnerabilities.... that's a big enough reason.
I guess you will need to wait for their Feb 2026 update.
You don't want a browser with a bunch of RCEs that can be triggered by opening a web page...
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.
They already made the mistake picking a niche language twice (first their own language, then Swift as a cross-platform language), why would you want them to make it a third time?
What kind of response is this? I was asking if there was any technical evaluation on other languages. And D and Ada are not niche. They have been battle tested in critical software.
Swift had/has some problems in the language itself. It's not because of the niche nature of Swift that was the problem iirc.
I don't think this is the right response because certainly a meaningful discussion could've definitely taken place and given how they were already open to other languages which was the reason why they picked Swift in the first place.
I remember Andreas video where he talked about how people used rust in his codebase and they were so happy but later it became very difficult whereas they found with swift that it became easier to manage. That was the reason why they picked swift that time.
Certainly their goal wasn't to pick a popular language (because if that's what you want use python or JS) but rather a language that was relevant to what they were building.
So if D and Ada were relevant or not, that's the main point of discussion imo.
I've dabbled a bit in Ada, but it wouldn't be my choice either. It's still susceptible to memory errors. It's better behaved than C, but you still have to be careful. And the tooling isn't great, and there isn't a lot in terms of libraries. I think Ladybird also has aspirations to build their own OS, so portability could also be an issue.
Not the case with spark. But I understand it requires writing lot of things from scratch for browsers. But I don’t think portability will be an issue with Ada, it is cross platform.
However, this is where d shines. D has a mature ecosystem. Offers first class cpp abi and provides memory safety guarantees, which the blog mentioned as a primary factor. And d is similar to cpp, low barrier for cpp devs to pick up.
There's no dynamic memory allocation with (100%) Spark. That's really limiting. You can to write "unsafe" code, but that has the same problems as Ada.
That is true for parsers like libjs, but again crypto module or even networking, can still be written in spark, which is much more safety critical.
SPARK is not used for the whole system, but for the < 5% parts, which are safety/security-related in a good architecture.
Probably contributing reasons? I imagine over time they will have a lot more Rust contributors than D or Ada.
Unfortunately a really good question gets downvoted instead of causing a relevant discussion, as so often in recent HN. It would be really interesting to know, why Ada would not be considered for such a large project, especially now when the code is translated with LLMs, as you say. I was never really comfortable that they were going for the most recent C++ versions, since there are still too many differences and unimplemented parts which make cross-compiler compatibilty an issue. I hope that with Rust at least cross-compilation is possible, so that the resulting executable also runs on older systems, where the toolchain is not available.
Unfortunately some folks do get bit sensitive on rust, that can be off putting.
But what I wanted to know was about evaluation with other languages, because Andreas has written complex software.
His insight might become enriching as to shortcomings or other issues which developers not that high up in the chain, may not have encountered.
Ultimately, that will only help others to understand how to write better software or think about scalability.
I personally think that people might've framed it as use Ada/D over rust comment which might have the HN people who prefer rust to respond with downvotes.
I agree that, this might be wrong behaviour and I don't think its any fault of rust itself which itself could be a blanket statement imo. There's nuance in both sides of discussions.
Coming to the main point, I feel like the real reason could be that rust is this sort of equilibra that the world has reached for, especially security related projects. Whether good or bad, this means that using rust would definitely lead to more contributor resources and the zeal of rustaceans can definitely be used as well and also third party libraries developed in rust although that itself is becoming a problem nowadays from what I hear from people in here who use rust sometimes (ie. too many dependencies)
Rust does seem to be good enough for this use case. I think the question could be on what D/Ada (Might I also add Nim/V/Odin) will add further to the project but I honestly agree that a fruitful discussion b/w other languages would've been certainly beneficial to the project (imo) and at the very least would've been very interesting to read personally
> which might have the HN people who prefer rust to respond with downvotes.
This completely misses the purpose of the downvoting feature, which is not surprising, since upvoting seems no longer to indicate quality or truth of the comment neither.
> rust is this sort of equilibra that the world has reached for, especially security related projects
Which is amazing, since Rust only covers a fraction of safety/security concerns covered by Ada/SPARK. Of course this language has some legacy issues (e.g. the physical separation of interface and body in two separate files; we have better solutions today), but it is still in development and more robust than the C/C++ (and likely Rust) toolchain. And in the age of LLMs, robustness and features of a toolchain should matter more than the language syntax/semantics.
> Rust does seem to be good enough for this use case.
If you compare it to the very recend C++ implementations they are using, I tend to agree. But if you compare it to a much more mature technology like e.g. Ada, I have my doubts.
> This completely misses the purpose of the downvoting feature
"Downvote for disagree" has been canonicalized on HN since (nearly) the beginning, by pg himself, back when he used his real-name account to comment. :)
I agree that it has undesirable consequences, but it is fully established.
Personally I would remove the downvote button entierly because apparently it is a lossy projection of an at least three-dimensional vector: agreement, quality, truth. Graying out text so it is no longer readable is a censoring measure not justified in most cases I encounter on HN in the eight years I'm here.
> If you compare it to the very recend C++ implementations they are using, I tend to agree. But if you compare it to a much more mature technology like e.g. Ada, I have my doubts.
I agree with you in the sense that it would've definitely been interesting to read what Andreas thinks of Ada/D and the discussion surrounding it and your overall comment too.
I do wish that anyone from ladybird team/maybe even Andreas if he's on HN (not sure) could respond to the original query if possible.
I remember ladybird had a discord server I once joined, perhaps someone from the community could ask Andreas about it there if possible since It would be genuinely fascinating to read.
Although a point I am worried about is if Ladybird changes the language again let's say after a discussion of using Ada/D. It might be awkward.
> I am worried about is if Ladybird changes the language again
In the time of good LLMs this is likely no longer a show-stopper (as e.g. the specific formating rules in C/C++ since there are good re-formating tools). The question is how long we will need programming languages at all. They were primarily invented because large assembler projects were too challenging for most people. But if all the complicated details can now be delegated to LLMs, strictly speaking, we no longer need programming languages either.
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).
You can checkout the pull requests related to LibJS: https://github.com/LadybirdBrowser/ladybird/pulls?q=is%3Apr+...
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)
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.
If this means we will get an independent state-of-the-art browser engine, I'm all for it.
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.
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.
you salty bro? XD
No, just saying facts
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
Oooh noooo I will have to fork it before it is too late!
Great! I can't wait they totally ditch C++
Using LibJS with servo, when?
> 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.
Apple’s own marketing speak has Swift as a cross platform language. Just like, I suppose, C# is a cross platform language.
Apple puts zero resources into making that claim reality, however.
Apple actually did put some resources behind it, the toolchain is reasonably pleasant to use outside macOS and Xcode, they have people building an ecosystem in the Swift Server Workgroup, and arguably some recent language design decisions don't seem to be purely motivated by desktop/mobile usage.
But in the end I can't help but feel Swift has become an absolute beast of a multi-paradigm language with even worse compile times than Rust or C++ for dubious ergonomics gains.
A language is more than a compiler. All of the Swift frameworks you would need to do anything actually useful or interesting in the language are macOS-only. You cannot develop in Swift for Windows/Linux/Android the way that you develop in Swift for macOS/iOS. That matters.
You don't need to convince me that Swift is poorly positioned there, but if you only care about server side (or possibly CLI) apps, the usable ecosystem on Linux isn't too shabby.
Does it make sense compared to C#, Go, Rust or a JVM language? I don't know, but it's there, and Apple put some resources behind the initiative.
I think it is comparable to C#, at least C# a decade or more ago. Back then it was a great language for developing GUI applications on Windows, Unity games, and that's about it. Now there's a blossoming community of cross-platform frameworks, but only because Microsoft invested in making those first-class. Apple hasn't been putting that effort into Swift.
Something of a culture clash here ain’t it, albeit an imbalanced one.
Good step. It will bring many more contributors.
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!
By 'Rust compiler' and 'C++ compiler', they refer to the LibJS bytecode generator implemented in those languages. This is about the generated JS bytecode.
Thanks! I was confused about this as well.
Yes, I re-read again, and I think you are correct. Thanks!
They're referring to LibJS's bytecode (the internal instruction stream of Ladybird’s JS engine), not to Rust/CPP output formats.
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.
Note that Firefox doesn't have market dominance. It is under 5% market share. That said I imagine Firefox users to be the most likely to make the jump. However, the web is a minefield of corner cases. It's hard to believe it will be enough to make the browser largely useful enough to be a daily driver.
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.
Maybe you're part of an anti-cult-cult?
Would be as bad as being in a cult.
Hate to tell you this, but it's cults all the way down. Plato understood this, and his disdain for caves and wall-shadows, is really a disdain for cults. The thing is, over the last 2300 years, we have gotten really good at making our caves super cozy -- much cozier than the "real world" could ever be. Our wall-shadows have become theme parks, broadway theaters, VR headsets, youtube videos, books, entire cities even. In Plato's day, it made sense to question the cave, to be suspicious of it. But today, the cave is not just at parity with reality, it is superior to it (similar to how a video game is a precisely engineered experience, one that never has too little signal and never has too much noise, the perfect balance to keep you interested and engaged).
I'm no mind reader, and certainly no anthropologist, but I suspect that what separates humans from other (non extinct) animals, is that we compulsively seek caves that we can decorate with moving shadows and static symbols. We even found a series of prime numbers (sequences of dots, ". ... ..... .......") in a cave from the _ice age_. Mathematics before writing. We seek to project what we see with our mind's eye into the world itself, thereby making it communicable, shareable. Ever tell someone you had a dream, and they believed you? You just planted the seed for a cult, a shared cave. Even though you cannot photograph the dream, or offer any evidence that you can dream at all.
The industrial and scientific revolutions have distanced our consciousness from this idea, even as they enabled ever more perfect caves to manifest. Our vocabulary has become corrupted and unclear. We started using words like "reality", and "literally", and "truth", when we mean the exact opposite.
The conspiracy theorists and cultists, are just people who wandered into a new cave, with a different kind of fire, and differently curved walls, and they want to tell people from their old cave that they have found a way out of the cave into reality -- they do not yet realize (or do not want to accept), that they live in a network of caves, a network of different things in the same category.
During the early 2020s, we did a lot of talking about the disappearance of "consensus reality". This is scientific terminology mapped over the idea of caves and cults. You can tell, because the phrase is an oxymoron. It is not reality, if it requires consensus. It is fantasy, it is fiction, it is a dream. The cave has indeed become so widespread that we even _call_ it reality.
If you speak language, and read words, you are participating in a cult (we even call caves that had a kind of altar in the center a cult -- in Eurasia, there was a cave-cult called _the cult of the bear_, which had a bear skull placed in its center during the last ice age, and I would not be surprised if people spoke to it, with the help of hallucinogens). The only question is whether the cult is nourishing you or cannibalizing you.
To the person you are responding to (user ocd): your cave (ladybird, your hypothetical tv-series), no longer nourishes you like it once did. Maybe find a new cave, build a fire in it. Unlike a television series, you can fork a code base. You make it into the perfect cave, just for you. And if another person likes this cave, chooses to sit by the fire with you, well, now you have a cult.
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.
So Swift didn't turned out like they imagined and Rust is just the next best alternative to that failed vision using Swift.
So far this is the first and only shift
They were doing their own custom language before Swift.
didn't know
> The browser and libraries are all written in C++. (While our own memory-safe Jakt language is in heavy development, it’s not yet ready for use in Ladybird.)
https://awesomekling.github.io/Ladybird-a-new-cross-platform...
only thing I could find - has it been actually used in Ladybird after all?
From the link it seems that Ladybird architecture is very modular, in this case LibJS is one of the subsystems that has less external dependencies, said that they don't need to migrate everything, only the parts that makes sense.
Yes, i understand that in a personal project, but they have investors behind them.
They adopted Rust for LibJS, not the browser and its engine.
I guess the ETA will pushed back by a few years then?
By 2 weeks so far ;-)
Probably not unless using Rust present some particular challenge for this type of project. But having eaten this proverbial apple they would probably use AI more and more assuming they have a budget and in this case being less rich than C++ might not mean much for productivity
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.
It's the opposite for me, most of the time it's first rough pass it generates is awful and if you don't have good taste and a solid background of years of experience programming you won't notice it and I keep having to tell it to steer into better design choices.
Is a migration from language X to Y or refactoring from pattern A to B really the kind of task that makes you look forward to your day when you wake up?
Personally my sweet spot for LLM usage is for such tasks, and they can do a much better job unpacking the prompt and getting it done quickly.
In fact, there's a few codebases at my workplace that are quite shit, and I'm looking forward to make my proposal to refactor these. Prior to LLMs, I'm sure I'd have been laughed off, but now it's much more practical to achieve this.
Right. I had a 100% manual hobby project that did a load of parametric CAD in Python. The problem with sharing this was either actively running a server, trying to port the stack to emscripten including OCCT, or rewriting in JS, something I am only vaguely experienced in.
In ~5 hours of prompting, coding, testing, tweaking, the STL outputs are 1:1 (having the original is essential for this) and it runs entirely locally once the browser has loaded.
I don’t pretend that I’m a frontend developer now but it’s the sort of thing that would have taken me at least days, probably longer if I took the time to learn how each piece worked/fitted together.
I'm not sure 25,000 lines translated in 2 weeks is "fast", for a naive translation between languages as similar as C++ and Rust (and Ladybird does modern RAII smart-pointer-y C++ which is VERY similar to Rust). You should easily be able to do 2000+ lines/day chunks.
Agreed, however, I'm quite sure 25,000 lines translated in "multiple months" is very "slow", for a naive translation between languages as similar as C++ and Rust.
Yeah, it also a lot that the person doing the translation is the lead developer of the project who is very familiar with the original version.
I imagine LLMs do help quite a bit for these language translation tasks though. Language translation (both human and programming) is one of the things they seem to be best at.
2000+ lines/day chunks are 10 days for 20+k lines...
I'm aware. What I meant is this is a reasonable output for a 1:1 translation by hand, without LLM use.
2000 lines a day feels like a lot to me if you want to be thorough.
"I will never be a world class athlete, so I play for the love of the sport."
Helps me.
Not sure why you'd get that from this post, which says it required careful small prompts over the course of weeks.
In the hands of experienced devs, AI increases coding speed with minimal impact to quality. That's your differentiator.
Look into platforms like Workato, Boomi, or similar iPaaS products, unfortunely it feels like those of us that like coding have to be happy turning into architect roles, with AI as brick layers.
It automates both the fun and the boring parts equally well. Now the job is like opening a box of legos and they fall out and then auto-assemble themselves into whatever we want..
Rather like opening a box of legos and reading them the instruction sheet while they auto assemble based on what they understood. Then you re-read and clarify where the assembly went wrong. Many times, if needed.
Used a LLM to translate their LibJS to Rust. Wonder why they didn't look into picking up where servo left off.
Servo isn't a JS engine. Do you mean why didn't they abandon their mission statement of developing a truly independent browser engine from scratch, abandon their C++ code base they spent the last 5 years building, accept a regression hit on WPT test coverage, so they can start hacking on a completely different complex foreign code-base they have no experience in, that another team is already developing?
Well for one, Servo isn't just JavaScript, it's an entire engine. Closer to Blink & Gecko.
Secondly, Ladybird wants to be a fourth implementor in the web browsers we have today. Right now there's pretty much three browser engines: Blink, Gecko and WebKit (or alternatively, every browser is either Chrome, Firefox or Safari). Ladybird wants to be the fourth engine and browser in that list.
Servo also wants to be the fourth engine in that list, although the original goal was to remove Gecko and replace it with Servo (which effectively wouldn't change the fact there's only three browsers/three engines). Then Mozilla lost track of what it was doing[0] and discarded the entire Servo team. Nowadays Servo isn't part of Mozilla anymore, but they're clearly much more strapped for resources and don't seem to be too interested in setting up all the work to make a Servo-based browser.
The question of "why not use Servo" kinda has the same tone as "why are people contributing to BSD, can't they just use Linux?". It's a different tool that happens to be in the same category.
[0]: Or in a less positive sense, went evil.
> Well for one, Servo isn't just JavaScript, it's an entire engine.
Notably Servo doesn't have it's own JS engine at all. It uses Rust bindings to SpiderMonkey.
Ladybird has a strong "all dependencies built in house" philosophy. Their argument is they want an alternative implementation to whatever is used by other browsers. I'd argue they would never use a third party library like servo as a principle.
No they don’t - SerenityOS did, but when Ladybird split out they started using all sorts of third party libraries for image decoding, network, etc.
Now a core part of the browser rendering engine is not something they’re going to outsource because it would defeat the goal of the project, but they have a far different policy to dependencies now than it used to before.
Because they're not servo and servo is still in the race. Merging those projects is against making an independent browser(s)
NIH syndrome
developers with good taste like Andreas Kling will be able to design entire OSes with coding agents
> design entire OSes with coding agents
They ported an existing project from CPP to Rust using AI because the porting would've been too tedious. I don't think they're planning on vibe coding PRs the way you're imagining.
Yeah, some weekends ago I tried writing a cross-platform browser without any Rust crates, this weekend I made my own self-hosted compile to Rust Clojure-like lisp, maybe next weekend attempting to create a OS that uses my language to run on bare-metal would actually be a challenge. Thanks for the inspiration :)
He already did
This comment raises an interesting question: Would Serenity OS have brought Andreas the same kind of serenity had it been developed with AI? Open candid question.
I don't think so because if I remember it correctly, Andreas suffered from alcoholism and serenity prayer helped him to go on the right path and iirc he honored that and created an os named serenityos.
God grant me the serenity
to accept the things I cannot change;
courage to change the things I can;
and wisdom to know the difference.
(courage to change the things I can;):- I think that this line must've given Andreas the strength, the passion to make the project reality.
but if AI made the change. Would the line be changed to courage to prompt an all powerful entity to change the things I asked it to.
Would that give courage? Would that inspire confidence in oneself?
I have personally made many projects with LLM's (honestly I must admit that I am a teenager and so I have been sort of using it from the start)
and personally, I feel like there are some points of curiosity that I can be prideful of in my projects but there is still a sense of emptiness and I think I am not the only one who observes it as such.
I think in the world of AI hype, it takes true courage & passion to write by hand.
Obviously one tries to argue that AI is the next bytecode but that is false because of the non deterministic nature of AI but even that being said, I think I personally feel as if the people who write assembly are definitely likely to be more passionate of their craft than Nodejs (and I would consider myself a nodejs guy and there's still passion but still)
Coding was definitely a form of art/expression/sense-of-meaning for Mr Andreas during a time of struggle. To automate that might strip him of the joy derived from stroking brush on an empty canvas.
Honestly, I really don't know about AI the more I think about it so I will not pretend that I know a thing/two about AI. This message is just my opinion in the moment. Opinions change with time but my opinion right now is that coding by hand definitely is more meaningful than not if the purpose of the project is to derive meaning.
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.
Nobody uses D
This is like the "real world" argument. Nobody uses that "in the real world", except well people that do.
And? Does it work? Because it does. It's a lot closer to C++ and you literally need like a week to start being productive and it's insanely flexible as a language. Nobody uses Swift also, but the additional problem with Swift was that it's entirely Apple-centric.
> Nobody uses Swift also
Yep, it was also a weird, not entirely pragmatic choice, even if it was well justified technically and all-in-all rational. D would be the same.
Entirely Apple-centric?