Ladybird adopts Rust, with help from AI
ladybird.org
ladybird.org
Also worth noting that "translated from C++" Rust is totally fine as a starting point. You can incrementally make it more idiomatic later once the C++ side is retired. The Rust compiler will still catch whole classes of memory bugs even if the code reads a bit weird. That's the whole point.
This is a HUUUGE reason code written in rust tended to be so much better than the original (which was probably written in c++).
Human expertise is the single most important factor and is more important than language.
Copy pasting from one language to another is way worse than complete rewrite with actual idiomatic and useful code.
Best option after proper rewrite is binding. And copy-paste with LLM comes way below these options imo.
If you look at real world, basically all value is created by boring and hated languages. Because people spent so much effort on making those languages useful, and other people spent so much effort learning and using those languages.
Don’t think anyone would prefer to work in a rust codebase that an LLM copy-pasted from c++, compared to working on a c++ codebase written by actual people that they can interact with.
But translating with automated tools is a much faster experiment.
Sometimes (not always), rewriting from scratch ends up in a big loss of time and resources and never replaces the old version.
Step 1 of any rewrite of a non-trivial codebase should should be parity. You can always refactor to make things more idiomatic in a later phase.
The sort of rewrite you're talking about can work well at an early stage of a project, in the spirit of Fred Brooks's "plan to throw one away". But for a mature browser like Ladybird that's trying to not break the user experience, it's much better to have a pure translation step, and then try to improve or refactor it later.
I feel the effort and frustration to have parity with LLM is more than doing a full rewrite without.
> Way too many rewrites fail because people try to "improve" things during the port
I think the last one gets ignored easily but my favorite time to document code is when reading it (but the best time is when writing it). It forces you to think explicitly about what the code is doing and makes it harder for the little things to slip by. Given that Ladybird is a popular project I really do think good documentation is a way to accelerate its development. Good documentation means new people can come in and contribute faster and with fewer errors. It lowers the barrier to entry, substantially. It's also helpful for all the mere mortals who forget things
Just give your users and fellow devs some basic respect. I mean would you be okay with me just handing our conversation over to an LLM? Honestly I'd be insulted if you did that. Why is this any different? Docs are how you communicate to users and fellow developers
Anyway I personally have asked LLMs to create more detailed TODO items for myself, on personal projects where I am the only human programmer who had laid eyes on the code. In fact, I do this frequently, including multiple times earlier today. So I don't take the idea seriously that using an LLM to generate a TODO comment is an inherently disrespectful thing to do.
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.
Don’t do that! On a two-day-old term?!
No wonder we’re called gatekeepers.
It's vibe engineering
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.
The difference now is they can get much further along.
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.
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.
I have a lot of sympathy for the Luddites after reading about the sudden loss of jobs and lifestyle, the new textile factories running roughshod over all sorts of ethical boundaries in pursuit of profit - like using child labour, and horrendous accident rates and working hours.
It's sad in a way the Luddites weren't more successful than they were, as there were decades of harm inflicted by these newfangled ideas before the kinks were ironed out. But some of the blame for that must be laid at the Luddites' feet - they were focused on preserving the past, choosing to remain in denial about the inevitability of the wave of change crashing down on them. They left the job of ironing out the kinks to the workers in the factories that displaced them.
With LLMs, we look be to taking the same broken path as the textile industry and its Luddites, sadly.
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.
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.
I absolutely hate how "slop" has lost its meaning.
"AI slop" was supposed to mean poor-quality content that's obviously AI-generated. But the anti-AI crowd has co-opted it to mean any AI-generated content, regardless of quality. EDIT: Or even the quantity of AI. Expedition 33 had a ton of critical acclaim and ended up winning tons of awards, yet once it was discovered that AI was used to generate some placeholder art, of which NONE of it was actually used in the final product, some people started labeling the game as AI slop. It's utterly ridiculous.
So now, we can't have conversations about AI slop without starting off with making sure everyone is on the same page on what the term even means.
EDIT: "Vibe coding" is suffering a similar fate. If I use AI to write some code, and I examine the code to make sure it doesn't have any obvious bugs or security issues, is that still vibe coding?
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.
(or generally: “Is the cocaine cartel comparison fair or unfair?”)
And in my experience potheads offer you a toke and if you politely refuse, no problem at all. Coke addicts don't want to take no for an answer and insist that everybody should do it, they get so much more done, decisions are faster and better and what the hell is wrong with you if you don't want some?
So, the users are similar too.
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.
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?
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!
>Imagine if I had written a comment to explain my intent for the function before I started writing the function body.
This in particular is not dissimilar from opening a chat with a model and giving it a prompt as usual but then adding at the end:
Begin your response below:
{ func> Imagine if I had written a comment to explain my intent for the function before I started writing the function body.
The loon programming language (a Lisp) has "semantic functions", where the body is just the doc comment.
"Bicycle for the mind", as always when it involves Jobs, sounds more fitting for the masses though, so thanks for sharing that :)
Though if apocalypse happens and all of our built tech goes away, we are in for a serious survival issu.
given that we've also lost the faculty to look at the past with anything other than contempt most people wouldn't even know what they miss. The little problem with losing the 'general cognition' department, just like broad social or cultural decline is that you lose the ability to even judge what you're losing, because the thing you just lost was doing the judging
A lot closer than you think, too
(1) It captures the ideal so well
(2) The bitter irony of how thoroughly pre-OS X Macintosh computers failed to live up to it
I feel like there's a similar dichotomy in LLM tools now
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 want less ambitious LLM powered tools than what's being offered. For example, I'd love a tool that can analyse whether comments have been kept up to date with the code they refer to. I don't want it to change anything I just want it to tell me of any problems. A linter basically. I imagine LLMs would be a good foundation for this.
One problem I've noticed is that both claude models and gpt-codex variants make absolutely deranged tool calls (like `cat <<'EOF' >> foo...EOF` pattern to create a file, or sed to read a couple lines), so it's sometimes hard to see what is it even trying to do.
I'm sure it can. I'd still like a single use tool though.
But that's just my taste. I'm very simple. I don't even use an IDE.
edit: to expand on what I mean. I would love it if there was a tool that has conquered the problem and doesn't require me to chat with it. I'm all for LLMs helping and facilitating the coding process, but I'm so far disappointed in the experience. I want something more like the traditional process but using LLMs to solve problems that would be otherwise difficult to solve computationally.
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 link also has a comparison to Skills further down.
https://code.claude.com/docs/en/output-styles#built-in-outpu...
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.
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!
The JMAP client itself is hosted here: https://seph.au/claude-webmail/
I can't prove this but its a purely static web app. You need a jmap server to use it. If you use stalwart, set:
server.listener.http.permissive-cors = true
server.listener.https.permissive-cors = true
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.
I honestly can't tell if this is a humorous attack or not.
Poe's law is validated once again.
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.
It's not, nor is it well informed. People are currently developing languages specifically for use by LLMs.
> It's not the best tool for the job for a lot of things
Then how could it possibly be the final language?
> if the LLMs make writing it as fast as anything else - whelp, I can't see any reason not to do it in Rust
This has nothing to do with the claim that it's the final language.
I used to think that I would never write C code again, but when I decided recently to build something that would run on ESP32 chips, I realized there wasn't any good reason for me to use Rust yet. ESP-IDF is built on C and I can write C code just fine. C compiles quickly, it's a very simple language on the surface, and as long as you minimize the use of dynamic memory allocation and other pitfalls, it's reliable.
My biggest problem with rust right now is enormous target/ dirs.
We're working on that and it should get better soonish. We're working on shared caches, as well as pruning of old cached builds of dependencies that are unlikely to be reused in a future build.
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).
Even rust has need of this. For example, I want a nopanic effect I can put on a function which makes it a compile error for anything that function calls to panic.
I really like how flix.dev looks, but there's always a little nagging at the back of my head that something like rust will always produce more performant software.
This!
This apart from build times is my biggest request for the language.
Nopanic, nomalloc, etc.
> Defect free.
I am an upstream developer on the Rust Project (lang, library, cargo, others), and obviously a big fan of Rust. This kind of advocacy doesn't help us, and in fact makes our jobs harder, because for some people this kind of advocacy is their main experience of people they assume are representative of Rust. Please take it down a notch.
I think Rust is the best available language for many kinds of problems. Not yet all, but we're always improving it to try to work for more people. It gets better over time. I'd certainly never call it, or almost any other software, "defect free".
And I'd never call it "the final language"; we're building it to last the test of time, and we hope things like the edition system mean that the successor to Rust is a future version of Rust, but things can always change, and we're not the only source of great ideas.
If you genuinely care about Rust, please adjust your advocacy of Rust to avoid hurting Rust and generating negative perceptions of Rust.
For a taste: I wish we didn’t need lifetime annotations, somehow. I wish rust had first class support for self borrows, possibly via explicit syntax indicating that a variable is borrowed, and thus pinned. Unpin breaks my brain, and I wish there were ways to do pin projections without getting a PhD first. I wish for async streams. I wish async executors were in std, and didn’t take so long to compile. I could go on and on.
I feel like there’s an even simpler & more beautiful language hiding inside rust. I can’t quite see it. But I really hope someone else can bring it into the world some day.
I would like all of that as well. I think we can do much of that in Rust. I would love to see self-borrows available, and not just via pinning; I would also like relative pointers. I would like people to almost never have to think about pin or unpin; one of my rules of thumb is that if you see Pin or Poll, you've delved too deep, and nobody should need those to write almost any async code, including the interiors of trait implementations and async runtime implementations. And I would absolutely like to see async iterators, async executors, and many kinds of async traits in the standard library.
I also think there are plenty of things we are unlikely to get to even in an edition, and that might never happen without a completely different language. I'm not sure if we'll find a path to doing those in Rust, or if they will be the domain of some future language that makes different trade-offs.
Yes, this is my feeling too. All programming languages - perhaps, all computer programs - must decide how malleable they should be. Fast moving systems are exciting, but they're very annoying to use, or build on top of. I think generally we want a very slow moving language for infrastructure software, like databases or the linux kernel. Slow moving languages are often good for users, because they don't need to learn new things or rewrite existing software. (I think thats one of the reasons python3 was so poorly received.)
It might be too late for large changes in rust. This a sign of maturity, but its also a little bit sad. I want all those features you mention too.
Some day. Maybe LLMs will help somehow. Rust is, thankfully, not the last programming language humans will invent.
> > Defect free.
There's a Google talk on the matter. "Defect rate" / "defect free" is a term that is used quite a bit. I've latched onto this, because I find it true. Rust is a far more defect free language on a line by line basis measured and compared to other statically typed languages.
> And I'd never call it "the final language"
I honestly disagree, and I'm sticking to this prediction.
I don't think we're going to be writing code much longer by ourselves. The machines are going to outpace us soon.
Maybe something that's LLM-oriented will take over, but at that point these won't be "human" languages anymore. So I'll revise my claim to "Rust is the last human language".
If I want to serialize my thoughts to code, Rust is the language for it. It's probably the last one I'll be hand-writing or sending my revisions back to the LLM for.
Rust will also be an order of magnitude easier to author, at which point there shouldn't be much holding people back from producing it. If you have a choice between generating Java, C++, Go, or Rust, you're going to pick Rust almost every time unless you have to fit into those other ecosystems.
If you haven't used Claude or Codex with Rust, it's sublime and you should drop what you're doing to try it.
As AI makes human-readable syntax less relevant, the Erlang/Elixir BEAM virtual machine is an ideal compilation target because its "let it crash" isolated process model provides system-level fault tolerance against AI logic errors, arguably more valuable than Rust’s strict memory safety.
The native Actor Model simplifies massive concurrency by eliminating shared state and the complex thread management. BEAM's hot code swapping capability also enables a continuous deployment where an AI can dynamically rewrite and inject optimized functions directly into live applications with zero downtime.
Imagine a future where an LLM is constantly monitoring server performance, profiling execution times, and dynamically rewriting sub-optimal functions in real-time. With Rust, every optimization requires a recompile and a deployment cycle that interrupts the system.
Finally, Erlang's functional immutability makes deterministic AI reasoning easier, while its built-in clustering replaces complex external infrastructure, making it a resilient platform suited for automated iteration.
We spend quite a lot of time conceptualizing around safe self mod and to build apps that can change at runtime. We ended up using custom Lua VM, type system to catch mistakes, declarative homogenous infrastructure and actor model (erlang inspired).
Actor model provides not just a good isolation but also it's much easier for AI to reason (since most of components are not that large), we already able to use it to write quite complex systems with ease.
Another upside - in actor model you don't really need any of this fluff with cron jobs, queues and etc, all the logic naturally maps to indended architecture, making implementation of agents _very_ easy.
https://wippy.ai/en/tutorials/micro-agi It takes 4-5 files to create mini sandboxed AI agent at top of actor model with ability to modify own toolkit while having system guardails and no access to core filesystem.
Bullshit walks.
RE: Claude Code, no I haven't used it, but I did do the Anthropic interview problem, beating all of Anthropic's reported Claude scores even with custom harnesses etc.
It's not a dunk that agents can't produce "as fast as can be" code; their code is usually still reasonably fast; it's just often 2-10x slower than can be.
Early on, these code agents wouldn't do basic good hygiene things, like check if the code compiled, avoid hallucinating weird modules, writing unit tests. And people would say they sucked ....
But if you just asked them to do those things: "After you write a file lint it and fix issues. After you finish this feature, write unit tests and fix all issues, etc ..."
Well, then they did that, it was great! Later the default prompts of these systems included enough verbiage to do that, you could get lazy again. Plus the models are are being optimized to know to do some of these things, and also avoid some bad code patterns from the start.
But the same applies to performance today. If you ask it to optimize for performance, to use a profiler, to analyze the algorithms and systemically try various optimization approaches ... it will do so, often to very good results.
Use it as if you're the tech lead managing a fresh hire. Tell it clearly what you want it to focus on and you get a much better result.
Claude’s toy email client gets closer to the speed limit than Gmail does. Why is Gmail so slow? I have no idea.
I asked a cursor agent to do the same for a geotiff to pmtiles converter. It managed to optimize the performance from tens of days to half a day for the case I wanted to solve.
And fyi, jmap is just a protocol for doing email over json & http. It’s not that hard to roll your own. Especially in a web browser.
Would be interesting to see it, did you publish it yet?
Only the client parts. And only the client parts its actually using. JMAP clients can be much simpler than servers. A JMAP server needs the whole protocol. JMAP clients only need to implement the parts they use. Servers also need to parse email message envelopes - which is way more difficult to do correctly than people think. JMAP clients can just use pre-parsed messages from the server.
Anyway, the code is here if you wanna take a look:
https://github.com/josephg/claude-mail
Claude put its JMAP API wrapper code in a child crate (confusingly also called jmap-client).
Live version: https://seph.au/claude-webmail/
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...
Wordpress loves to shove php objects into the database (been a good long while since I used it, don't remember the mechanism, it'd be the equivalent of `pickle` in python, only readable by php).
Not sure if they've improved it since I last dealt with it about 15 years ago, but at the time there was no way to have a full separated staging and production environment, lots of the data stored in the database that way had hardcoded domain names built into it. We needed to have a staging and production kind of set-up, so we ended up having to write a PHP script that would dump the staging database, fix every reference, and push it to production. Fun times.
No idea what's used in wordpress, but back in D6 and before, it was common to see it when it would store multiple values for an instance.
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 :-)
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.
No that’s a stretch, but firing up a AAA game.
How long time do we have to wait before these people get bored? Or might they actually find what they generate useful and it doesn't all go straight to /dev/null, since seemingly it seems to gain usage, not drop in usage?
At least it gives _something_ back. Until of course we've obsoleted all of them as well.
Most of the AAA games I've paid for sit there in my Steam library and never get played. At least _some_ of the money probably went to those talented people whose work was used for training GenAI and coding models (and yes I say this as someone who has used all of these tools to prototype my own games, and still think human created content is of a much higher quality, just more expensive to produce).
But let's be honest to ourselves, the sort of useless code the GP meant will never ever be used for any of that. The code will never leave their personal storage. In that sense it's about as valuable for the society at large as the combined exabytes of GenAI smut that people have been filling their drives with by running their 4090s 24/7.
The node binary is huge due to inclusion of i18n libraries to support the native APIs, and should have little impact on memory consumption. There is a way to opt out.
The C10K was a long-solved problem when Node came out; just it was not for what 99% of people used at the time, i.e. PHP/Python/Ruby.
I’ve been throwing codex at them and now they’ve all been rewritten in Go - cut down to about 10mb per process.
All my vibe coded projects are human directed, unless explicitly stated otherwise
> 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.
Is this a conventional goal? It seems like quite an achievement.
Porting a project from PHP7 to PHP8, you'd want the exact same SQL statements to be sent to the server for your test suite, or at least be able to explain the differences. Porting AngularJS to Vue, you'd want the same backend requests, etc..
I used Claude to rewrite it in golang and extend its features. Now I have tests, automatic AIA chain walking, support for all the DER and JKS formats, and it’s fast. My bash script could spend a few minutes churning through a folder with certs and keys, my golang version does a few thousand in a second.
So I basically built a limited version of OpenSSL with better ergonomics and a lot of magic under the hood because you don’t have to specify input formats at all. I wasn’t constrained by things like backwards compatibility and interface stability, which let me make something much nicer to use.
I even was able to build a wasm version so it can run in the browser. All this from someone that is not a great coder. Don’t worry, I’m explicitly not rolling my own crypto.
In my coding agent std::slop I've optimized for this workflow https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode... basically the idea is that you are the 'maintainer' and you get bisect safe, git patches that you review (or ask a code reviewer skill or another agent to review). Any change re-rolls the whole stack. Git already supports such a flow and I added it to the agent. A simple markdown skill does not work because it 'forgets'. A 'github' based PR flow felt too externally dependent. This workflow is enforced by a 'patcher' skill, and once that's active, tools do not work unless they follow the enforced flow.
I think a lot of people are going to feel comfortable using agents this way rather than going full blast. I do all my development this way.
Would be curious to see more about how you save tokens with lua too.
Do you blog?
- A bit more on mail mode https://x.com/hsaliak/status/2020022329154420830
- on the Lua integration https://x.com/hsaliak/status/2022911468262350976 (I've since disabled the recursion, not every code file is long and it seems simpler to not do it), but the rest of it is still there
- hotwords for skill activation https://x.com/hsaliak/status/2024322170353037788
Also /review and /feedback. /feedback (the non code version) opens up the LLM's last response in an editor so you can give line by line comments. Inspired by "not top posting" from mailing lists.
* domain experts paying for tooling that will enhance their productivity
* capital/management class hoping to significantly replace domain experts
Software devs have been a famously tough market to sell tools to for a long time, so the better bet is B. Plus, the story on B is fantastic for fundraising; if there's a 10% chance that it checks out, you want some part of that as your capital portfolio.
I see it all the time at the Director and VP level. Once big money is on the line, there are no failures, just "opportunities for strategic realignment"
And you might say that this is a hypothetical problem, one that is not practically occurring. Well, we had a similar problem like this in the recent past, that LLMs are close to _making actual_. When it comes to software patents, they were considered a _hypothetical_ problem (i.e. nobody is going to bother suing you unless you were so big that violating a patent was a near certainty). We were instructed (at pretty much all jobs), to never read patents, so that we cannot incriminate ourselves in the discovery process.
That is going to change soon (within a year). I have friend, whom I won't name, who is working on a project, using LLMs, to discover whether software (open source and proprietary) is likely to be violating a software patent from a patent database. And it is designed to be used, not by programmers, but by law firms, patent attorneys, etc. Even though it is not marketed this way, it is essentially a target acquisition system for use by patent trolls. It is hard for me to tell if this means that we will have to keep ignoring patents for that plausible deniability, or if this means that we will have to become hyper informed about all patents. I suppose, we can just subscribe to the patent-agent, and hope that it guides the other coding agents into avoiding the insertion of potentially infringing code.
(I also have a friend who built a system in 2020 that could translate between C++ and Python, and guarantee equivalent results, and code that looks human-written. This was a very impressive achievement, especially because of how it guarantees the equivalence (it did not require machine-learning nor GPUs, just CPUs and some classic algorithms from the 80s). The friend informs me that they are very disheartened to see that now any toddler with a credit card can mindlessly do something similar, invalidating around a decade of unpublished research. They tell me that it will remain unpublished, and if they could go back in time, they would spend that decade extracting as much surplus from society as possible, by hook or by crook (apparently they had the means and the opportunity, but lacked the motive); we should all learn from my friend's mistake. The only people who succeed are, sadly, perversely, those who brazenly and shamelessly steal -- and make no mistake, the AI companies are built on theft. When millionaires do it, they become billionaires -- when Aaron Swartz does it, he is sentenced to federal prison. I'm not quite a pessimist yet, but it really is saddening to watch my friend go from a passionate optimist to a cold nihilist.).
If there was value (the guarantees) to this tech he buried a bunch of time in, he should be wrapping a natural language prompt around it and selling it.
Not even the top providers are giving any sort of tangible safety or reliability guarantees in the enterprise…
No, they are quite terrible at doing that.
They may (I guess?) produce code that compiles, but they will, almost certainly not produce the appropriate combination of idioms and custom abstractions that may the code "at home" in the target language.
PS - Please fix your blockquote... HN ignores single linebreaks, so you have to either using pairs of them, or possibly go with italicization of the quoted text.
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.
> ... the entire port took about two weeks.
So he was ~halfway in when he made the Swift announcement.
Not anymore.
Next month it will be yet-another-language.
Eventually they come full circle and settle for either C or C++.
I've seen another team doing something similar, they went through endless rewrite cycles of a major package but never shipped, and eventually the project was axed when they proposed to do it all over again, but this time even better.
https://github.com/LadybirdBrowser/ladybird/tree/8017f8a7ed3...
The core browser engine, JS/CSS/layout etc will always be original.
> Indeed, and as a school those 18 months are well worth it, but it is in many ways also 18 months wasted.
* of course i'm just an internet person, i don't deserve anything from anybody ^^
Not just volatility but also flip-flopping. Rust was explicitly a contender when they decided to go with Swift 18 months ago, and they've already done a 180 on it despite the language being more or less the same as it was.
For the Ladybird project, now is the best time to be making a big decision like this, and it's commendable that the project lead was honest to recognize when an earlier attempt was not working, to be able to re-think and come to a better decision. I'm no fan of Rust, but for this project I think most of us would agree it's a better language than Swift for their purpose.
A release (?)
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.
Ladybird will have to deliver eventually - on this part I think many people agree with.
By this definition all basic research is hype.
> monopolies
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.
And experience doesn't equal correct decision making. People just get traumatized in different ways.
This rings very true, and I've actually disadvantaged myself somewhat here. I was involved in projects that made very dubious decisions to rewrite large systems in Rust. This caused me to actively stay away from the language, and stick to C++, investing lots of time in overcoming its shortcomings.
Now years later, I started with Rust in a new project. And I must say, I like the language, I really like the tools, and I like the ecosystem. On some dimension I wish I would have done this sooner (but on the other hand, I think I have a better justification of "why Rust" now).
1. build / compile times can be atrocious
2. crates.io inherits the npm philosophy, which means fairly unmoderated space of third party deps and because the Rust stdlib doesn't have a lot in it, extensive third party crate (lib) usage is strong in Rust. As a result most Rust projects have rather sprawling dependency trees, often with duplicated functionality (multiple Base64, rand, sha256, etc crates). I personally have a problem with this (auditability, accountability, security, complexity etc). Others don't.
3. Despite being nominally runtime agnostic, Rust async basically is tokio and it's almost impossible to use another runtime once you factor in third party deps. In many ways Rust is the language that tokio ate. In fact even if you opt out of async entirely, you often end up with tokio as a dependency simply because the community just seems to expect it.
4. Despite advertising itself as a "systems" language, some basic systems programming facilities I expect from my C++ background are still fundamentally not there. In particular, per-container/struct pluggable allocators still isn't a thing and the feature to add it (allocator-api) has sat unmerged in nightly for almost ten years at this point and it doesn't look good for it landing any time soon.
5. If you're working in the embedded space, there's still plenty of devices that will not have a workable Rust toolchain option yet.
I still choose it for new projects instead of its competitors C++ or Zig. But I think it's important to recognize there are compromises like any other tool.
As much as people might insist otherwise, there will in fact come a day when there are "multiple Rusts" by which I mean multiple styles and ways of doing things -- just like C++. For myself, for example... if it were my repository and my team and my hiring, and I was starting from scratch... I'd be extremely careful about third party crate adoption and have an extremely minimalistic approach there. And I don't use tokio. Though my paying jobs do.
I don’t think this is true unless they differ in major versions no? Cargo will apply semantic versioning and pick the best available given the cargo.toml version constraints.
tho duplicated crates with different major versions through transitive deps is also i believe possible
The compile times are easily the worst part though. They couple poorly with (2).
I feel fine personally without (3), and (4)/(5) don't come up for me.
> For myself, for example... if it were my repository and my team and my hiring, and I was starting from scratch... I'd be extremely careful about third party crate adoption and have an extremely minimalistic approach there.
Same. I basically stick to a minimal `cargo-vet` and avoid new crates. I review new ones. I've chosen to take on a new crate when it's something like "the author literally wrote the spec for this format", but otherwise I'm reluctant.
I never fell in love with Rust or got particularly excited about adopting it. But, I just don't see a serious alternative (maybe Swift is fine for some cases but not in my field).
I believe Google's Rust journey was even more closely aligned with Ladybird: "we want memory safety, but with low impedance mismatch from C++". After like 5 years of trying to figure something like that out they seemed to go "OK actually fuck that we just have to use Rust and deal with the challenges it brings for a C++ shop".
Definitely isn’t one of those things that can be solved, but it’s helpful to be aware of and process on that basis. I think some personalities are likely disproportionately vulnerable to this behaviour, but I think it largely has a positive core of enthusiasm. It’s probably more a matter of those individuals growing in self awareness.
Perhaps we saw a big wave of that with rust because it meant a lot of things to a lot of different people, some more equip to express their enthusiasm with some self control than others.
if it works it works i guess, but it seems mad to me on the surface
the relevant bit here is that he's porting from a language in which he has plenty of experience into another one in which he doesn't, in a large project
that in itself sounds like putting a lot of faith in LLMs but maybe there are factors not mentioned here, which is why i said "on the surface"
Also, as others have pointed out, "someone with no experience" simply isn't true.
you're banking in the LLMs quite strongly when you do that, which may just work but i would be very worried about myself if i were in his boots
He did write it.
> you're banking in the LLMs quite strongly when you do that, which may just work but i would be very worried about myself if i were in his boots
I too would worry if it were you doing it.
he did not, the LLM did it
> I too would worry if it were you doing it.
i would not worry about anything you do, because it's obvious you would never get to that point
> i would not worry about anything you do, because it's obvious you would never get to that point
Childish whatabouting and projection. I will never respond to you again.
I mean, they seem mostly to be against anything that isn't C++'s peculiar brand of Object Oriented Programming?
(also against women and immigrants, but that's a different story)
Doesn't sound like it's some Fish-style, full migration to Rust of everything. Seems like they are just moving a couple parts over for evaluation, and then, going forward, making it an official project language that folks are free to use. They note that basically every browser already does that, so this isn't a huge shakeup.
Personally I think most programming languages have really ... huge problems. And the languages that are more fun to use, ruby or python, are slow. I wonder if we could have a great, effective, elegant language that is also slow. All that try end up with e. g. with a C++ like language.
Rust, although annoying at a micro scale, does at least enforce some structure on your code, although like Kling I miss OO.
AI has made Rust approachable to a new audience of programmers who didn't want to dedicate their life to learning the ins and outs of the language. Especially for C++ developers who already learned the ins and outs of a hyper complex programming language and don't want to go through that a second time.
Before AI, writing Rust was frustrating experience that involved spending 90% of your time reading documentation and grumbling that "I could do this in 5 minutes in C++"
Now I can write Rust in a way that makes sense to my C++ addled brain and let the AI do the important job of turning it into an idiomatic Rust program that compiles.
I wouldnt go as far as to say, I dont like Rust, but it doesnt come natural to me like many other languages do after several decades of experience.
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.
Wary of what?
Long read on the topic (quite funny, covers Cluely): https://harpers.org/archive/2026/03/childs-play-sam-kriss-ai...
This doesn't mean that being agentic cannot be cultivated by regular people.
In 2026, yes, agency matters more than skill/wisdom/intelligence to get VC funds. But what's the point of agency alone if you are leading such a life?
What gives me hope is that in 2026, skillful people can delegate a lot of their work to LLMs, which gives them time to learn the "agentic" part which is basically marketing and talking with people.
(just thinking out loud)
You get to good at schmoozing the compiler you start to create actual logical bugs faster.
If I recall correctly, part of this was around classes they had that replaced parts of the STL, whereas the Swift C++ interop makes assumptions about things with certain standard names.
We’re at the point where a solid test suite and a high-quality agent can achieve impressive results in the hands of a competent coder. Yes, it will still screw up, needs careful human review and steering, etc, but there is a tangible productivity improvement. I don’t think it makes sense putting numbers on it, but for many tasks, it looks like there’s a tangible benefit.
LLM and rust rewrite together. And it does work so hopefully they get more attention and build it so I have an alternative browser to use
The truth is more simple: he's a good engineer and leader, people recognised that and offered him sponsorships, and the project took off by itself.
There are many examples of good engineers that are also good leaders. I think the Venn overlap isn't that unusual, at least for a good engineer leading a team up to maybe a dozen. When a good engineer lands in a spot where they get to work on something they really care about, that doesn't hurt either!
Now, how many good engineers are also good at leading larger teams? As the team size increases, my impression is that it is less common. If so, why? Lots to explore around individual, cultural, and corporate factors.
* If one sets a prior probability to 0 or 1, a posterior probability will not change due to Bayes' Rule. This means new information has no effect. Put another way, choosing either 0 or 1 as a prior is equivalent to stating "no new information will change my belief."
IIRC he used to work on the Safari browser engine at Apple.
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.
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.”
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.
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.
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.
Maybe we would see similar effects adopting Modern C++. Maybe not. The article doesn't tell us.
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.
What does the memory safety even matter when hackers poison heavily used crates?
[1]: https://developer.chrome.com/blog/memory-safety-fonts
[2]: https://github.com/googlefonts/fontations/tree/main/skrifa
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.
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)
- 99% of the ~700 crates were done compiling in about a minute or 2 - RocksDB (a C++ dependency) was 2 minutes by itself - And then it took 10 minutes (ten!) just for the final binary at the end.
That's not normal for Rust code at all. Even large ones like Servo or Rustc or Zed.
UPDATE2: turns out they have LTO enabled by default. Disabling that brings the compile time down to 7 minutes. But that's still really unexpectedly slow.
I definitely agree that it's too slow. I just don't think the cause is "too many dependencies" because I've compiled Rust codebases with twice as many dependencies in half the time!
It seems to produce a 94MB binary. So it may be partly that there are some very big dependencies. But the amount of compilation time that ends up in the top-level crate (even with LTO disabled) also makes me feel like this must be triggering a compiler bug. Either that or using far too many generics.
I've hit compiler bugs that behave this way. Here's one from an LLVM upgrade [1]. The test case I discovered apparently took over 20 minutes to compile, up from 26 seconds on stable! Their value tracking algorithm was accidentally quadratic.
Ah yes, my never-ending crusade to raise awareness that the cost of free (as in effort) dependencies is bloat.
You can make useful tools that are tiny and compile fast [1], but it takes a lot of effort; exactly what developers don't want to spend.
[1]: Like https://github.com/parasyte/hd -- And I wrote about one of the tricks that it uses: https://blog.kodewerx.org/2023/04/improving-build-times-for-...
Not quite. It doesn't have tagged unions, which is what I expect you are thinking of, but it does have sum types.
Go doesn’t have sum types as a first class primitive.
But they're not tagged unions. I expect that is still where your confusion lies. Tagged unions and sum types are not equivalent. Tagged unions are a subset of sum types.
AFAIK, tagged union is sum type, based on sum type mathematical definition.
Sum types are a type definition defining something as A or B. Not “anything that quacks like a duck”. But concretely “one of this or one of that”. This enables different syntax, like the match expression to be used, in which you exhaustively list all the variants. The compiler doesn’t need to heap allocate enums because it knows the maximum size of a single value. The compiler and programmer can take advantage of the knowledge that there’s a closed set of values the type can hold. It’s not an open type class.
Result and Option are quite beautiful as sum types. But they’re horrible as type classes. Try implementing them using interface{} in Go. It’s not the same.
But can also define a closed set of types, perfectly satisfying "sum types".
> This enables different syntax, like the match expression to be used, in which you exhaustively list all the variants.
Go does not provide this out of the box, but that is not prerequisite for sum types. The mathematical theory says nothing about "the compiler must produce an error if the user doesn't match call cases". There is sufficient information provided by the sum types if you wish to add this to your build chain yourself, of course.
This argument feels like the “we have sum types at home” meme. Ergonomics matter.
I write a lot of rust. Rust has traits which are similar to Go’s interfaces. But the features aren’t the same, and I use enum all the time. (I also use trait all the time, but I use trait and enum for different things).
No. That doesn't make any sense. void* is essentially equivalent to any in Go, which isn't sum types either.
You can construct sum types in C by combining structs, enums, and unions, but it is not an out of the box feature like in Go. Sum types are a first-class citizen in Go.
> Ergonomics matter.
Math doesn't care about ergonomics. You might care about ergonomics, but logically when talking about those ergonomics you'd call those ergonomics by name, not by some unrelated thing from type theory.
Maybe I'm misunderstanding what you mean. Can you give me an example? How would you write a Result type in Go? (Result is defined as either Ok(val) or Err(err))
enum result_type {
OK,
ERROR
};
union result_value {
int value;
char *error_message;
};
struct result {
enum result_type tag;
union result_value value;
};
Go:
type Result interface {
isResult()
}
type OK[T any] struct {
Value T
}
func (OK[T]) isResult() {}
type Error struct {
Message string
}
func (Error) isResult() {}
The data says otherwise, three overflows and two UAFs this month in Chrome alone: https://www.cvedetails.com/vulnerability-list/vendor_id-1224...
> People need to learn how to use tools properly.
there is a good chance Rust will start dying and will actually die by being replaced by some new hyper-overengineered lang much faster than C++ actually die.
"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?
Also CDDA:Bn wouldn't damn need a > 40h long build using 1.5 GB of RAM under an n270 netbook. Ditto with Nchat, FFS, which is worse. A Golang counterpart for nchat as a TG client (and tdlib rewritten in Go) would weight far less while compiling and maybe even the binary itself, and performance wise it would be similar.
I still remember tons of C++ projects from 2005-2009 impossible to compile today but with GCC 4.3 or GCC 4.9, can't remember. Not because of the size, but because C++ incompatible changes over the years. At least tons of C code will compile it today as is modulo some POSIX changes from C code pre 1996. C++ it's something that should died long ago, among stuff like locales under Unix. UTF8 everywhere, use your own currency and the like.
Yeah, I know, game engines, and tons of physics engines and libraries even FLOSS ones such as OGRE, gdal and the like are C++ domain. Still, most of these could be ported to C.
Likewise, trying to write pure C or C++ services in iOS or Android is more pain than gain.
> 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.)
Rarely if ever is anything able to compete simply by being "better". As far as USPs go it's just not enough. I reckon for ladyboy the USP (if any) is going to be it being open and NOT chrome (or derivative). So "safe" "modern" language is not going to mean much to the end users.
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.
In Ladybird's case, tests they could rely upon.
It's about Netscape. By the time, Netscape had dominated the browser market. It was the leader and that means they had all the market share to lose. You can bet Microsoft's decision makers were very closely monitoring what those at Netscape were doing.
Today, practically nobody uses Ladybird. No one even knows it[1]. It's so behind and has nothing to lose. If you really want to rewrite, it's better to do it when you have nothing to lose.
[0]: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
[1]: to quote Joel, "no one" means less than one million people.
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.
Out of all the languages rust takes inspiration from, id rank C++ at the top of the list.
OOP, weakly-typed templates, and mutable aliasing create impedance mismatch in almost every C++ API.
Rust doesn't have data inheritance, and what looks like interface inheritance is merely extra requirements in a flat list of traits, so subclassing won't behave like C++ APIs expect. When you translate a class hierarchy to Rust, it needs lots of crutches which make it weird, boilerplatey, and tedious to use. There's no good recipe for OOP hierarchy in Rust, because the idioms are so different. The mismatch feels like writing an ORM.
For some C++ APIs mutability and circular references can be a pain too. Rust works well with DAG data structures and clear mostly-immutable data flow. Objects with some "parent" pointer are common in C++, but Rust sees them as potentially dangling, with shared mutable state, and requires much heavier control of them. It can be done, but it's ugly. Idiomatic Rust designs go to great lengths to avoid it unless necessary, but C++ APIs can have the extra pointers "for convenience".
There's a reason why Rust doesn't have typical GUI libraries - an arbitrary web of references between widgets and event handlers make it ugly in Rust, and that's on top of a view class inheritance.
C++ templates sit very uncomfortably between Rust's macros (duck typed) and Rust's generics (strictly typed at point of declaration).
C++ templates almost always are a mix of types they're attached to and some duck-typing in their expansion.
Rust's generics do not allow any duck typing at all. This makes translation of even a tiny bit clever C++ templates a chore. There's no specialization. No way to deal with SFINAE and such.
Rust macros have flexibility for all the syntax shenanigans (and even similarly bad errors at instantiation time), but macros can't see any types. Idiomatic Rust has very deliberate division between traits (usually much simpler and smaller in scope), macros and proc macros/derives. Splitting C++ templates like that can be a major redesign.
See Component Software: Beyond Object-Oriented Programming, first edition 2002.
Also the way Microsoft is implementing their windows-rs crate, and WDK for Rust.
In the grander scheme of things, Java and C# are literally the same language, Rust and C++ are twins, C is their dad, Forth is the owl staring through the dining room window, and Erlang is an alien spaceship passing over the house.
> C is their dad
You can write "C with classes" in the "C/C++/Rust" language, and have users of all three tell you you're doing it wrong. The commonalities between them are mostly necessities of systems programming, FFI, and LLVM-style optimizations, but they all try to get there in different ways.
> There are far more exotic languages out there. APL. Erlang. Forth
Early Rust started as an Erlang clone, with task supervision trees and all (panics, lock poisoning, and the defunct UnwindSafe trait are vestigial features from that experiment).
Rust has more in common with Ocaml than C or C++. It's not a C family language, it just took C-like syntax to avoid the stigma of being "exotic" like the languages that inspired it.
Rust did copy move semantics from C++, but even that ended up being different enough to be incompatible with basic C++ design patterns. Rust chose to have only trivially movable types and guarantee absence of move constructors, so it can't even safely pass a C++ std::string.
I agree that Rust has very conventional C-like syntax, but I'd go further and say it has fairly conventional C-like semantics too, at least in its current iteration. I think you could safely duck type Rust itself as a C-like. :)
Strong agree that Rust has drawn great inspiration from the ML family by way of OCaml. Rust is a C-like with ML characteristics, which are its greatest quality, imho. On the other hand, I don't think there's much trace of Erlang left in Rust -- there's probably more Erlang in Go than Rust, and Go is squarely a C-like.
I think it's fair to say that Rust started out more exotic than it is now, but perhaps all that safe, C-like syntax has led to convergent evolution towards other C-likes?
> Rust did copy move semantics from C++, but even that ended up being different enough to be incompatible with basic C++ design patterns. Rust chose to have only trivially movable types and guarantee absence of move constructors, so it can't even safely pass a C++ std::string.
Right, but compare all of that to Erlang's actor-based message passing, where mandatory immutability averts the need to move or lock anything at all, and I think it's clear why one would group Rust with C++, and not Erlang.
That's the biggest difference to C++ and most mainstream languages, you simply can't do OOP (which in my books is a good thing) and it forces you more towards traits and composition.
the hard bit (borrow checker) has still to be done...
Testing has become 10x as important as ever.
I am already using low code tooling with agents for some projects, in iPaaS products.
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.
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.
I think, changes to languages/tooling to accomodate Agentic loops will become important.
> All of this assume that you care even a tiny bit about what is happening in your code. If you don't...
I mean, as software engineers, we most certainly do. I suspect there'll be a new class of "developers" who will have their own way of making software, dealing with bugs, building debugging tools that suit their SDLC etc. LLMs will be to software development what Relativity was to Astrophysics, imo: A fundamental & permanent shift.
IMO Rust will strike a very strong balance here for LLMs.
Hardly much different than dealing with traditional offshoring projects output.
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.
I don't understand what you mean. Beat any language at what? Correctness? I don't think that's true at all, but I also don't see how that's relevant, it definitely doesn't address the fact that Rust will virtually always produce faster code than the majority of other languages.
> Hardly much different than dealing with traditional offshoring projects output.
I don't know what you mean here either.
Also there is the alternative path to execute code via agents workestration, just like low code tooling work.
I see you never had the fortune to review code provided by cheap offshoring teams.
I guess that's sort of technically true, but not even really? Like, obviously you can compile Python to C and then compile that with clang, but it doesn't make it fast. But even if that were the case, there aren't that many languages that have Rust performance so who cares? "Potentially" is sort of saying we might have a future language that's better, but of course anyone would agree.
> Also there is the alternative path to execute code via agents workestration, just like low code tooling work.
I don't understand how this is relevant.
> I see you never had the fortune to review code provided by cheap offshoring teams.
I just don't understand why you're bringing it up tbh I don't understand the relevance.
Plenty of AI based tooling is already trying out this path.
Agents execute actions that in the past would be manually programmed applications, now tasks can be automated given a few mcp endpoints.
LLMs are already at the same output quality of lousy offshoring companies, thus having to fix a bit of it is something that unfortunately many of us are already used with fellow humans.
> Well, I am on the provocative side that as AI tooling matures current programming languages will slowly become irrelevant.
And I said I disagree because language directly impacts things like performance. And it does, massively. Like, order of magnitude differences are not hard to achieve simply by changing language.
You are now saying that things just need to be "fast enough", but I don't get how that's relevant. The point is that a different language will have different tradeoffs, and AI changes some of the calculus there, but language is still a major component of the produced artifact. If you agree that language has major implications on the produced artifact, then we agree. If you don't, then I'll just once again appeal to the massive performance gaps between different languages.
I still am not understanding the offshoaring conversation.
Only because you focus too much into the frontend, instead of the whole compiler infrastructure, with multiple frontends for the same compilation pipeline.
> I still am not understanding the offshoaring conversation.
Because you never had to review human written code by cheap offshoring teams, zero difference with LLM generated code quality, even today.
I see the opposite. New languages have more difficulty breaking into popularity due to lack of enough existing codename and ecosystems.
I've been doing a few projects that are definitely outside my comfort zone with LLMs and its fine. I can read the code but I just don't have the muscle memory to produce it.
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.
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.
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.
The part that concerns me is whether this part will actually come in time or not:
> The Rust code intentionally mimics things like the C++ register allocation patterns so that the two compilers produce identical bytecode. Correctness is a close second. We know the result isn’t idiomatic Rust, and there’s a lot that can be simplified once we’re comfortable retiring the C++ pipeline. That cleanup will come in time.
Of course, it wouldn't be the first time Andreas delivered more than I expected :).
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.
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.
The Ladybird devs painted themselves in a corner when choosing C++ for a new web browser, with many anti-Rust folks claiming that "modern C++ was safe". Well...
That choice was never made. C++ was selrcted as the language of choice for SerenityOS. Since the goal of the OS was to make its founder happy, and C++ was his faviourite language at the time, that seems like an obvious choice. Later, as part of SerenityOS, there was a need for an HTML parser. It was written in C++ as was the rest of the operating system. Then that HTML parser evolved into a full web browser. As part of the SerenityOS project, that browser was written completely in C++. Then that web browser forked off into an independent project...
Ladybird was already a fully functioning browser (not finished of course but complete enough to surf many web pages) when it was forked from SerenityOS to create a stand-alone web browser. The choice at that point was "keep evolving the current C++ code base" or start-over. I doubt the second option was even considered.
They have been evaluating other languages since before the fork. Rust was evaluated and rejectd early-on. They even created their own language at one point. https://github.com/SerenityOS/jakt
Perhaps, but in fairness the project was started in 2018 when Rust was still new and unproven.
> You can't compare the choices made to evolve a >20 years old codebase with a brand new one.
I guess not, but I'm pretty optimistic about Ladybird's ability to adopt Rust if they want to. It's a much smaller codebase than Firefox (~650K LoC).
This initial PR is already ~25k LoC, so approximately 4% of the codebase. It took 1 person 2 weeks to complete. If you extrapolate from that, it would take 1 person-year to port the whole thing, which is not so bad considering that you could spread that work out over multiple years and multiple people.
And Firefox has shown that the intermediate state where you have a mix of languages is viable over the long term, even in a much larger and more complex codebase.
Rust was already proven in 2018, and I'm pretty sure they went with C++ for other reasons.
Thankfully Servo has picked up speed again and if one wants a Rust based browser engine what better choice than the one the language was built to enable?
But I'm also cheering along Ladybird's progress. There's definitely room for more than one project in the space. And IMO the more browsers being built in Rust in the better.
it is totally possible to use some strict subset of C++, which will be memory safe.
I work on such project, where we use simplified C++, and it works fine, no memory corruptions in my experience.
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 puts zero resources into making that claim reality, however.
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.
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.
And if you mean before the whole .NET Core rewrite, many big corp server applications were already written in .NET, products like SharePoint, Sitecore, Optimizely, Dynamics 365, Four51,.... and plenty of server infrastructure for XBox and Windows games.
Have you actually used .NET on Linux/macOS? I have (both at home and work) and there isn't anything that made me think it was neglected on those platforms. Everything just works™
[1] Swift was first created in 2010, 16 years ago and officially launched in 2014, 12 years ago, by a huge multi-billion dollar corporation. The same corporation has launched hundreds of products and services in the same time period. If they really wanted Swift to be cross platform at a competitive level (Java, .Net, Python, JS, etc), they would have done it by now.
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 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?
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
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.
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.
“the Rust ecosystem around browsers is growing” – in the beginning pretty much 100% of the ecosystem around Rust was browser oriented
Thankfully Servo is picking up speed again and is a great project to help support with some donations etc: https://servo.org/
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.
> classic HackerNews title shortening algorithm
It wasn't the cause of this change; the submitter submitted it without the “with help from AI” part, for some reason.
There is an open PR (by simonw btw): https://github.com/minimaxir/hacker-news-undocumented/pull/4...
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
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
https://github.com/anthropics/claude-plugins-official/pull/1...
Ladybird is much further ahead in terms of actually rendering web pages that people use.
The biggest advantage to Servo was that it is written in Rust. This move begins to nullify that advantage as well.
Why exactly does Servo make more sense?
I hope they both succeed. But Ladybird is more likely to become a usable browser first.
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.
for example: "Swift fails to import clang modules with #include <math.h> with libstdc++-15 installed. Workaround: None (!!)"
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)
Yeah but, you can do the same in 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.
[1]: https://www.swift.org/documentation/cxx-interop/
[2]: https://www.swift.org/blog/improving-usability-of-c-librarie...
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).
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.
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.
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
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.
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.
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.
"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.
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.
Attackers are surprisingly resilient to partial security.
Its purpose is not to reinvent everything. It’s not a hype project.
While rust is nice on paper, writting complex software in it is mentally consuming. You can not do it for a long time.
Does this still get you most of the memory-safety benefits of using Rust vs C++?
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?
So, even though they want the code base to be in Rust, they will continue writing new code in C++ and then translating it to Rust later to remove the C++ they just added.
There must be a really good reason for this, such as Rust doesn’t interop well with C++, otherwise this seems like a poor decision.
I don't know that that is the reason, given the opening lines of the article:
We’ve been searching for a memory-safe programming language to replace C++ in Ladybird for a while now. We previously explored Swift, but the C++ interop never quite got there, and platform support outside the Apple ecosystem was limited. Rust is a different story. The ecosystem is far more mature for systems programming, and many of our contributors already know the language. Going forward, we are rewriting parts of Ladybird in Rust.
Yea, I'd bet it's that. Ideally, you'd want to stop writing C++ and continue with Rust on all new code, but Rust has stricter semantics, so the interop is somewhat "easy" in one direction, but very hairy in the other direction.
This means that in practice, you want to start porting from leaf components and slowly grow closer to the root, which stays in C++ for quite some time and just calls into Rust through C API (or something close to it).
If you're curious about the topic, there's a interop library called Zngur (https://hkalbasi.github.io/zngur/), which is built on this assumption. They have a pretty good explanation of the concrete problems on the homepage.
I am very interested to know if this time and energy spent actually improved memory safety.
Other engineers facing the same challenges want to know!
On the rust side, the question is how much `unsafe` they used (I would hope none at all, although they don't specify).
I am not trying to dunk on the effort; quite the contrary. I am eager to hear more about the goals it originally set out to achieve.
It seems like it is used mostly for FFI.
If they had developed a technique to get a modern C++ compiler and rustc to generate exactly the same output for any program (even a trivial one) I think that would be huge news and I would love to see all the linker hacking that would involve.
It could have been worse. C++ code naively converted line-by-line to Rust typically results in weird and unsafe Rust, but in this case it seems they've only been strict about the results being the same, not the structure of the implementation.
Rewrites have a very high risk of introducing regressions. Trying to fix bugs while rewriting will only make things harder, because instead of simply comparing outputs exactly, you'll have to judge which output is the right one. If you let the behavior significantly diverge during the rewrite, you'll just have two differently buggy codebases and no reference to follow.
It's much easier to make a bug-for-bug compatible copy, and fix bugs later.
This project, of all of them, throwing in the towel on AI makes me fear AI abstainers have no future.
they learn Rust
it takes a couple of years
it's not that hard.
I guess it's a long way off, since the LLM translation would need to be refactored into natural Rust first. But the value of it would be in that it's a real world project, and not a hypothetical "well, you could probably just...".
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.
I'm confused about this part. What part of the browser did they want GC and inheritance for? I'd get it if they were writing the UI in this, but the rest of this post is about the JS engine. They weren't going to 1:1 map JS objects to Swift objects and rely on ARC to manage memory, were they?
You can model these with reference counting, but this turned out unfeasible in browsers. There's a great talk from when Blink (Chrome) transitioned from reference counting to GC, which provides a lot more details about these problems in practice: https://www.youtube.com/watch?v=_uxmEyd6uxo
> I'd get it if they were writing the UI in this, but the rest of this post is about the JS engine.
I think this might be the reason they started with the JS engine and not with some more fundamental browser structures. JS object model has these problems, too, but the engine has to solve them in more generic way. All JS objects can just be modeled as some JSObject class/struct where this is handled on the engine level.
DOM and other browser structures are different because the engine has to understand them, so the browser developers have to interact with the GC manually and if you watch the talk above, you'll see that it's quite involved to do even in C++, let alone in Rust, which puts a bunch of restrictions on top of that.
I watched some of his streams on the development of the JIT compiler (what this change set seems to replace) on one of his streams, and was blown away by the quality of Copilot generated suggestions/completions on an (under-represented) domain (x86 opcodes, etc). This was before Claude Code et al, and pretty early-on for LLM tooling.
The inevitable cleanup that will follow this could be done the same way. Refactoring like that can be done in more bite sized chunks, which makes it easier to review what is happening and control how it is done.
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 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?
EDIT: bramhaag pointed out the error of my ways. Thanks bramhaag!
i had high hopes for ladybird to become an alternative browser anyone with a working C++ compiler could build on whatever platform.
Given it's not launched and it's donor driven, I guess conserving developer time is a key priority? Dual track sucks lots of time?
I've translated it from Rust to V in 45 minutes. Works great:
https://github.com/medvednikov/libjs_v
Compiles in 0.2 seconds on my M5 (compared to Rust's 3.3 seconds).
Rust syntax is a PITA and investing a lot of effort in the language doesn’t seem worth the trouble for an experienced C++ developer, but with AI learning, porting and maintenance all become more accessible. It’s possible to integrate Rust in an existing codebase or write subparts of larger C++ projects in Rust where it makes sense.
I was recently involved in an AI porting effort, but using different languages and the results were fine. Validating and reviewing the code took longer than writing it.
> 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.
From what I can tell from HN, Brave seems to be popular with those users who hate Google but for whatever reason hate Mozilla even more, and I suspect those will be the most likely users to switch.
That's a lot of people contributing.
How many of them will be less willing to contribute in the future, and less productive when they do if a sizable portion is in Rust? Maybe there'll be more contributions and maybe there'll be less. I don't know. If you've managed to develop a community of 1200 developers who are willing to advance the project why upset the applecart?
Ah, but I see they actually haven't done that to most of their code, so maybe it's just a bit of pandering to the hype and fashion.
In the hands of experienced devs, AI increases coding speed with minimal impact to quality. That's your differentiator.
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.
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 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.
Helps me.
There is no evidence of that coming from this post. The work was highly directly by an extremely skilled engineer. As he points out, it was small chunks. What chunks and in what order were his decision.
Is AI re-writing those chunks much faster than he could. Yes. Very much so. Is it doing it better? Probably not. So, it is mostly just faster when you are very specific about what it should do. In other words, it is not a competitor. It is a tool.
And the entire thing was constrained by a massive test suite. AI did not write that. It does not even understand why those tests are the way they are.
This is a long way from "AI, write me a JavaScript engine".
Both will get a skilled craftsman to the point where thie output is a quality piece of work. Using the autotoools to prepare the inputs allows velocity and consistency.
Main issue is the hype and skiddies who would say - feed this tree into a machine and get a cabinet.Producing non-detrministic outputs with the operator being unable to adjust requirements on the fly or even stray from patterns/designs that havent been trained yet.
The tools have limitiations and the operators as well , and the hype does adisservice to what would be establishing reasonable patterns of usage and best practices.
Would be as bad as being in a cult.
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.
Naturally this will be somewhat critical, but I need to first put things into context. I do believe that we really need an alternative to Google dominating our digital life. So I don't object that we need alternatives; whether Ladybird will be an alternative, or not, will be shown in the future. Most assuredly we need competition as otherwise the Google empire moves forward like Darth Vader and the empire (but nowhere near as cool as that; I find Google boring and lame. Even skynet in Terminator was more fun than Google. Google just annoys the heck out of me, but back to the topic of browsers).
So with that out of the way ... Ladybird is kind of ... erratic.
Some time ago, perhaps two months or three, Andreas suddenly announced "Swift WILL BE THE FOREVER FUTURE! C++ sucks!!!". People back then were scratching heads. It was not clear why Swift is suddenly our saviour.
Ok, now we learn - "wait ... swift is NOT the future, but RUST is!!!". Ok ... more head-scratching. We are having a deja-vu moment here... but it gets stranger:
"We previously explored Swift, but the C++ interop never quite got there, and platform support outside the Apple ecosystem was limited. Rust is a different story."
and then:
"I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation"
So ... the expertise will be with regards to ... relying on AI to autogenerate code in ... Rust.
I am not saying this is a 100% fail strategy, mind you. AI can generate useful code, we could see that. But I am beginning to have more and more doubts about the Ladybird project. Add to this the breakage of URLs that are used by thousands or million people world-wide (see the issues reported on the github tracker); or also the fact that, once you scale-up and more and more people use ladybird, will you be able to keep up with issue trackers? Will you ban more people?
In a way it is actually good that I am no longer allowed to make comments on their repository because I can now be a lot more critical and ask questions that the ladybird team will have to evaluate. Will ladybird blend? Will it succeed? Will it fail? Yes, it is way too early to make an evaluation, so we should evaluate in some months or so, perhaps end of this year. But I am pretty certain the criticism will increase, at the least the moment they decide to leave beta (or alpha or whatever model they use; they claimd they want a first working version in this year for Linux users, let's see whether that works).
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.
The project's use of AI now echoes that - it's not being used to create new features, it's used for practical, boring drudge work of translating between two languages. So still very much on brand.
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.
I'm not sure how I'd feel if I woke up and found a system I worked on had been translated into an another language I'm not neccessarily familiar with. And I'm not sure I'd want to fix an non-idiomatic "mess" just because it's been translated into a language I'm familiar with either (although I suspect they'll have no problem attracting rust developers).