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!
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.
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.
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.
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.
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.
This is the way. Coding assistants are also really great at porting from one language to the other, especially if you have existing tests.
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.
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.
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.
Same thing.
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.
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".
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 "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.
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!
Would be as bad as being in a cult.
this entire project starts to look like "how am i feeling today?" rather than a serious project.
So far this is the first and only shift
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).
Well, what else is there besides the obvious? It's a browser.
Why isn't that enough?
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.
Not anymore.
Testing has become 10x as important as ever.
I am already using low code tooling with agents for some projects, in iPaaS products.
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.
They're not porting the browser itself to Rust, for the record.
EDIT: bramhaag pointed out the error of my ways. Thanks bramhaag!
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.
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.
> Ralph Wiggum loop
I wonder what kind of tech debt this brings and if the trade off will be worth whatever problems they were having with C++.
> 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.
throwaway2027•1h ago