We're adopting Rust as our C++ successor language, and using AI agents to accelerate the transition.
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.
Why Rust?
When we originally evaluated Rust back in 2024, we rejected it because it’s not great at C++ style OOP. The web platform object model inherits a lot of 1990s OOP flavor, with garbage collection, deep inheritance hierarchies, and so on. Rust’s ownership model is not a natural fit for that.
But after another year of treading water, it’s time to make the pragmatic choice. Rust has the ecosystem and the safety guarantees we need. Both Firefox and Chromium have already begun introducing Rust into their codebases, and we think it’s the right choice for Ladybird too.
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.
I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go. After the initial translation, I ran multiple passes of adversarial review, asking different models to analyze the code for mistakes and bad patterns.
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. We’ve verified that every AST produced by the Rust parser is identical to the C++ one, and all bytecode generated by the Rust compiler is identical to the C++ compiler’s output. Zero regressions across the board:
| Test suite | Tests | Regressions |
|---|---|---|
| test262 | 52,898 | 0 |
| Ladybird regression tests | 12,461 | 0 |
No performance regressions on any of the JS benchmarks we track either.
Beyond the test suites, I’ve done extensive testing by browsing the web in a lockstep mode where both the C++ and Rust pipelines run simultaneously, verifying that output is identical for every piece of JavaScript that flows through them.
If you look at the code, you’ll notice it has a strong “translated from C++” vibe. That’s because it is translated from C++. The top priority for this first pass is compatibility with our C++ pipeline. The Rust code intentionally mimics things like the C++ register allocation patterns so that the two compilers produce identical bytecode. Correctness is a close second. We know the result isn’t idiomatic Rust, and there’s a lot that can be simplified once we’re comfortable retiring the C++ pipeline. That cleanup will come in time.
What’s next
This is not becoming the main focus of the project. We will continue developing the engine in C++, and porting subsystems to Rust will be a sidetrack that runs for a long time. New Rust code will coexist with existing C++ through well-defined interop boundaries.
We want to be deliberate about which parts get ported and in what order, so the porting effort is managed by the core team. Please coordinate with us before starting any porting work so nobody wastes their time on something we can’t merge.
I know this will be a controversial move, but I believe it’s the right decision for Ladybird’s future. :^)
Andreas Kling
Founder & President
Read the original article
Comments
The byte-for-byte identical output requirement is the smartest part of this whole thing. You basically get to run the old and new pipelines side by side and diff them, which means any bug in the translation is immediately caught. Way too many rewrites fail because people try to "improve" things during the port and end up chasing phantom bugs that might be in the old code, the new code, or just behavioral differences.
Also worth noting that "translated from C++" Rust is totally fine as a starting point. You can incrementally make it more idiomatic later once the C++ side is retired. The Rust compiler will still catch whole classes of memory bugs even if the code reads a bit weird. That's the whole point.
I'd say that porting is a great time to "improve" many things, but like you suggest, not a great time to add new features. You can do a lot of improvements while maintaining output parity. You're in the weeds, reading the code, thinking about the routines, and you have all the hindsight of having done it already. Features are great to add as comments that sketch things out but importantly this is a great time to find and recognize that maybe a subroutine is pretty inefficient. I mean the big problem in writing software is that the goal are ever evolving. You wrote the software for different goals, different constraints. So a great time to clean things up, make them more flexible, more readable, *AND TO DOCUMENT*.> Way too many rewrites fail because people try to "improve" things during the portI 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
By JuniperMesos 2026-02-240:351 reply LLMs are great at producing documentation - ask one "hey can you add a TODO comment about the thing on line 847 that is probably not the best way to do this?" while you're working on the port, and it will craft a reasonably-legible comment about that thing without further thought from you, that will make things easier for the person (possibly future-you) looking at the codebase for improvements to make. Meanwhile, you keep on working on the port that has byte-for-byte identical output.
By al_borland 2026-02-248:111 reply If I’m writing that anyway, to tell the LLM, why wouldn’t I just write the comment myself?
I guess to have the LLM write a lengthy descrption of why the code is bad? Otherwise it doesn't make sense to ask an LLM instead of typing // TODO: bad coding style.
Why do I want length? Good docs are terse. Longer isn't better. When I read docs I want to get to know the developer and what they're thinking. I want to see their vision, not their calculator. It's not about quantity, it's about quality.
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
By JuniperMesos 2026-02-249:36 Concision is one of several virtues in documentation, and it trades off against thoroughness. I don't actually want to get to know the developer when I read a comment in some piece of code I am reading or editing, I want to as quickly and accurately as possible understand what I need to know about that code to make the changes I care about at that time.
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.
By ale42 2026-02-2412:52 I didn't say that length was a requirement, I was only thinking about why one would want to use an LLM to write a comment that is only a few words long, while the prompt might be as long as the (short version of the) comment itself.
I hope, with the velocity unlocked by these tools, that more pure ports will become the norm. Before, migrations could be so costly that “improving” things “while I’m here” helped sell doing the migration at all, especially in business settings. Only to lead to more toil chasing those phantom bugs.
By ozgrakkurt 2026-02-2320:284 reply One of the biggest point of rewriting is you know better by then so you create something better.
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.
> Copy pasting from one language to another is way worse than complete rewrite with actual idiomatic and useful code.
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.
By drzaiusx11 2026-02-242:03 I've seen more than a few rewrite attempts fail throughout the years. However, I've never seen a direct language to language translation fail. I've done several of these personally: from perl to ruby, java to kotlin, etc.
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.
By arduanika 2026-02-2322:55 These are two different kinds of rewrites, for two different kinds of codebases, in two different situations. The important thing is to know which kind of rewrite you're doing, and have the whole team onboard.
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.
By ukblewis 2026-02-2320:48 It depends on your goals. If your only initial goal is to ensure the safety of your code, and that is rather important for a browser!
By Foobar8568 2026-02-245:40 I rewrote two times my personal tool, one to rust, and out of rust with LLM, I mainly "vibe code" for reasons but the tool is more complete and less buggy than most B2B and enterprise business or IT software that I have seen in 20years at different fortune 100.
I feel the effort and frustration to have parity with LLM is more than doing a full rewrite without.
That reminds me of the "Strangler Fig" pattern where you replace a service by first sending the requests to both the old and new implementation so you can compare their outputs. Then only when you're confident the new service functions as expected do you actually retire the old service.
By CuriouslyC 2026-02-2414:10 The key part of the strangler fig is the facade and gradual migration of capabilities rather than trying to do a rewrite and swap (which never ends well).
By hparadiz 2026-02-2321:14 I did several web framework conversions exactly like this. Make sure the http output string matches in the new code exactly as the old code and then eventually deleted the old code with full confidence.
By dreis_sw 2026-02-2321:27 Works even better if you have a good test suite, which is surely the case here with Ladybird
By chupchap 2026-02-2323:59 Really like this translation approach and I had written about it just couple of days back (more from a testing and validation context). To see folks take that approach to something complex is pretty amazing! https://balanarayan.com/2026/02/20/gen-ai-time-to-focus-on-l...
> I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go. After the initial translation, I ran multiple passes of adversarial review, asking different models to analyze the code for mistakes and bad patterns. > The requirement from the start was byte-for-byte identical output from both pipelines. The result was about 25,000 lines of Rust, and the entire port took about two weeks. The same work would have taken me multiple months to do by hand. We’ve verified that every AST produced by the Rust parser is identical to the C++ one, and all bytecode generated by the Rust compiler is identical to the C++ compiler’s output. Zero regressions across the board
This is the way. Coding assistants are also really great at porting from one language to the other, especially if you have existing tests.
> Coding assistants are also really great at porting from one language to the other
I had a broken, one-off Perl script, a relic from the days when everyone thought Drupal was the future (long time ago). It was originally designed to migrate a site from an unmaintained internal CMS to Drupal. The CMS was ancient and it only ran in a VM for "look what we built a million years ago" purposes (I even had written permission from my ex-employer to keep that thing).
Just for a laugh, I fed this mess of undeclared dependencies and missing logic into Claude and told it to port the whole thing to Rust. It spent 80 minutes researching Drupal and coding, then "one-shotted" a functional import tool. Not only did it mirror the original design and module structure, but it also implemented several custom plugins based on hints it found in my old code comments.
It burned through a mountain of tokens, but 10/10 - would generate tens of thousands of lines of useless code again.
The Epilogue: That site has since been ported to WordPress, then ProcessWire, then rebuilt as a Node.js app. Word on the street is that some poor souls are currently trying to port it to Next.js.
> 10/10 - would generate tens of thousands of lines of useless code again.
Me too! A couple days ago I gave claude the JMAP spec and asked it to write a JMAP based webmail client in rust from scratch. And it did! It burned a mountain of tokens, and its got more than a few bugs. But now I've got my very own email client, powered by the stalwart email server. The rust code compiles into a 2mb wasm bundle that does everything client side. Its somehow insanely fast. Honestly, its the fastest email client I've ever used by far. Everything feels instant.
I don't need my own email client, but I have one now. So unnecessary, and yet strangely fun.
Its quite a testament to JMAP that you can feed the RFC into claude and get a janky client out. I wonder what semi-useless junk I should get it to make next? I bet it wouldn't do as good a job with IMAP, but maybe if I let it use an IMAP library someone's already made? Might be worth a try!
Same here. I had Claude write me a web based RSS feed reader in Rust. It has some minor glitches I still need to iron out, but it works great, is fast as can be, and is easy on the eyes.
By chwtutha 2026-02-2315:15 Haha glad to see someone else did something like this. A couple weeks ago I asked Claude to recommend a service that would allow me to easily view a local .xml file as an RSS feed. It instead built a .html RSS viewer.
Re "is fast as can be": in my experience generating C/Zig code via Codex, agent generated code is usually several multiples slower than hand optimized code.
Yeah, I’m sure my Claude generated email client could be even faster if I wrote it by hand. Modern computers can retire billions of instructions per second per core. All operations that aren’t downloading or processing gigabytes of data should be instant on modern computers.
Claude’s toy email client gets closer to the speed limit than Gmail does. Why is Gmail so slow? I have no idea.
I find the sweet spot is to take LLM generated code, then profile manually and heavily supervise or hand implement specific improvements.
By patates 2026-02-245:46 You can also let the agent use a profiling tool. It probably cannot beat you, but does find and improve a lot of things for sure.
Look, it's an RSS reader, not a numeric solver for PDEs. What I clearly meant was: Every interaction is instant, no noticable delay at all, except the reader view, which makes a network request to an external site.
Hey, sorry, I just have to defuse assumptions people make when they see Rust, LLMs, and "as fast as can be" in short proximity. Your project is obviously cool, and I don't think the fact that it's likely still multiples more resource intensive than an absolutely minimal version takes away from that.
By __mp 2026-02-242:28 you have to ask it to profile and optimize the code for you. Then have it document the changes and run it in a loop. It’ll do wonders.
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.
Given parent and GP are both using Claude... have you tried Claude? (I say this as someone who has not tried Claude recently. I did try Claude Code when it first came out, though.)
First, it is important for these discussions that people include details like I did. We're all better off to not generalize.
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.
There is a lot to be done with good prompting.
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.
By josephg 2026-02-240:38 Yep. Claude code is best thought of as an overachieving junior / mid. It can run off and do all sorts of work on its own, but it doesn't have great instincts and it can't read your mind about what you want.
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.
By srcreigh 2026-02-242:36 That's a given, and agents still come out 2-10x slower in my experience.
Rust is the final language.
Defect free. Immaculate types. Safe. Ergonomic. Beautiful to read.
AI is going to be writing a lot of Rust.
The final arguments of "rust is hard to write" are going to quiet down. This makes it even more accessible.
By JoshTriplett 2026-02-2319:584 reply > Rust is the final language.
> 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.
I’d also add: as a lover of forward progress, I really hope rust isn’t the last good idea programming language designers have. I love rust. But there are dozens of things I find a bit frustrating. Unfortunately I don’t think I’m clever & motivated enough to write a whole new language to try to improve it. But I really hope someone else is!
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.
By JoshTriplett 2026-02-241:231 reply > 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 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.
By josephg 2026-02-245:29 > 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.
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.
By echelon 2026-02-2413:38 I'm sorry my autistic elation for Rust is perceived as being over the top, but I truly do mean everything I say. I could have articulated it in a less saccharine tone.
> > 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.
By estebank 2026-02-2320:06 As a member of t-compiler, seconded.
By jacquesm 2026-02-2320:27 Thank you, thank you, thank you.
By tmtvl 2026-02-2314:24 > Beautiful to read.
Oh my, there's a new language called Rust? Didn't they know there already is one? The old one is so popular that I can't imagine the nicely readable one to gain any traction whatsoever (even if the old one is an assault on the senses).
> Rust is the final language.
I honestly can't tell if this is a humorous attack or not.
Poe's law is validated once again.
It's honest. If we can serialize our ideas to any language for durability, Rust is the way to go.
It's not the best tool for the job for a lot of things, but if the LLMs make writing it as fast as anything else - whelp, I can't see any reason not to do it in Rust.
If you get any language outputs "for free", Rust is the way to go.
I've been using Claude to go ridiculously fast in Rust recently. In the pre-LLM years I wrote a lot of Rust, but it definitely was a slow to author language. Claude helps me produce it as fast as I can think. I spend most of my time reviewing the code and making small fixes and refactors. It's great.
While Rust is excellent, you must acknowledge that Rust has issues with compilation time. It also has a steep learning curve (especially around lifetimes.) It's much too early to say Rust is the "final" language, especially since AI is driving a huge shift in thinking right now.
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.
If you're programming for ESP, then embassy is the way to go in most cases. You don't need to learn much about lifetimes in most of the application code. Steep learning curve people refer it is "thing blow up at compile time vs runtime." It's easy to write JS or C that passes all tests and compiles and then wonderful blows up when you start using it. It just forces you to learn things you need to know at IMO right now.
My biggest problem with rust right now is enormous target/ dirs.
By JoshTriplett 2026-02-2320:001 reply > 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.
By tvshtr 2026-02-2323:25 thanks beejesus! (aka the devs) I'm tired of forcing shit into workspaces just to slightly mitigate these issues
By Foobar8568 2026-02-245:53 I feel compilation time is unbearable in Rust, even on MacBook pro M3 max, don't get me started on space
By sdkfjhdsjk 2026-02-2315:31 [dead]
By klsdjfdlkfjsd 2026-02-2315:362 reply I'll just stick with C as my lingua franca, and won't be involving Microsoft in my programming life, thanks.
By klsdjfdlkfjsd 2026-02-2319:083 reply [flagged]
By drdeca 2026-02-2319:46 Anthropic? ChatGPT is the one affiliated with Microsoft.
By robjellinghaus 2026-02-2319:39 Not Microsoft.
You’re thinking of OpenAI and ChatGPT, which has a (now-rocky) partnership with Microsoft.
Claude is an Anthropic offering.
By klsdjfdlkfjsd 2026-02-2319:50 [flagged]
> It's honest.
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.
By jibal 2026-02-2419:30 What did I say that is false?
By dontblokmebro70 2026-02-2319:16 [flagged]
By johnebgd 2026-02-2316:25 Sometimes I forget programming languages aren't a religion, and then I see someone post stuff like this. Programming languages really do inspire some of us to feel differently.
By the__alchemist 2026-02-2316:04 I would say it's overall the best existing language, probably due to learning from past mistakes. On the whole it wins via the pro/con sum. But ... Still loads of room for improvement! Far from a perfect lang; just edges out the existing alternatives by a bit.
I'd say that it's taking much needed steps to achieve perfection but many more steps are there ahead. The next language closer to perfection would definitely have a much gentler introduction curve, among other things.
By DANmode 2026-02-2319:39 Which coding assistant do you think needs a gentle introduction curve?
By pabs3 2026-02-255:12 Rust lacks dependent typing, which advanced languages like Idris2 have.
By tekne 2026-02-2314:01 Needs monads (not joking)
By jungojango 2026-02-2412:24 If AI gets sufficiently good what will be the point of rust? I can just whip out some C code, tell the AI to make it safe (or just ask it if the code contains any undefined behavior), done.
Why not go full functional programming at that point? If the main issue with FP has been accessibility, then it should really take off now.
When you do fully value-oriented programming in Rust (i.e. no interior mutability involved) that's essentially functional programming. There's mutable, ephemeral data involved, but it's always confined to a single well-defined context and never escapes from it. You can even have most of your code base be sans-IO, which is the exact same pattern you'd use in Haskell.
By theLiminator 2026-02-2322:531 reply I actually like rust more than Haskell, but `You can even have most of your code base be sans-IO, which is the exact same pattern you'd use in Haskell.` glosses over the fact that in Haskell it's enforced at compile time.
Another argument as to why rust isn't the forever-language. My forever language should include effects!
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.
By theLiminator 2026-02-244:57 Though I think it's the closest language right now, ideally you have something that is close to "zero-overhead" as your forever language.
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.
By echelon 2026-02-2413:47 > 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.
This!
This apart from build times is my biggest request for the language.
Nopanic, nomalloc, etc.
I wouldn’t because idiomatic Haskell is way slower than idiomatic Rust.
By jimbokun 2026-02-2316:58 Isn’t Rust a pretty good functional language? It has most of the features that enable safe, correct code without being anal about immutability and laziness that make performance difficult to predict.
By nineteen999 2026-02-2412:11 Working code talks.
Bullshit walks.
By wolvesechoes 2026-02-2315:25 [flagged]
Rust may be the darling of the moment, but Erlang is oft slept on.
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.
I can't comment on production viability today but if you assume that language itself is irrelevant then it becomes clear that runtime and engine level is the way to go.
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.
By basch 2026-02-2517:58 I guess at a high level im thinking about what kind of running systems are the easiest to edit as they execute. Maybe I should have even picked clojure for being homoiconioc and not needing to be parst into an ast. The LLM can traverse, prune, graft and transform s-expressions directly with perfect structural accuracy.
Please post this. I'd love to play with it and, especially, see how fast it is.
By easterncalculus 2026-02-2323:211 reply Seconding this comment, as someone who loves JMAP.
By josephg 2026-02-240:14 Code is here: https://github.com/josephg/claude-mail
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:
orserver.listener.http.permissive-cors = true
Then you should be able to put https://localhost:8080/ into the URL box. It should also work with fastmail, but I haven't tested it.server.listener.https.permissive-cors = true
Just curious, does it look anything like this library?
Also curious why would one be proud of having an LLM rewrite something that there is already a library for. I personally feel that proud LLM users boasting sounds as if they are on amphetamines.
Not sure I understand, wouldn’t a webmail client in rust need client code like this or to use a library like this?
Yeah but it’s like saying, “why are you impressed with Claude making a car when there are plans for an engine online?”. Even if Claude used that code (it didn't), it made the whole car. Not just an engine. There’s a lot more stuff going on than simply calling a backend mail server over jmap.
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.
Your initial claim talked about jmap and this looks to me like a full implementation of the RFC in rust. That is the hard part of an email client IMO so I’m not sure I’d agree with your analogy, but you’re saying it made a web app which called a library like this?
Would be interesting to see it, did you publish it yet?
> looks to me like a full implementation of the RFC in rust
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).
By grey-area 2026-02-246:26 Cool thanks.
By yc-kraln 2026-02-2323:35 Interesting! I am getting tired of looking at Roundcube and having weird issues and was thinking of doing the same. Were you planning on making the result public?
Did you use dioxus? I had claude write up a test web app with it, but when attempting to use a javascript component it built it couldn't get past memory access out of bound errors.
By josephg 2026-02-2323:41 I used leptos. Before I started I made a text file containing the entire leptos manual, and told claude to read it. I don't know if that helped, but claude seems to use it just fine.
Sure; I’ll throw it online in a few hours when I’m at my computer.
By josephg 2026-02-240:15 Code is here: https://github.com/josephg/claude-mail
Live version: https://seph.au/claude-webmail/
By tapstapstaps 2026-02-2323:57 [dead]
> It burned through a mountain of tokens, but 10/10 - would generate tens of thousands of lines of useless code again.
This is the biggest bottleneck at this point. I'm looking forward to RAM production increasing, and getting to a point where every high-end PC (workstation & gaming) has a dedicated NPU next to the GPU. You'll be able to do this kind of stuff as much as you want, using any local model you want. Run a ralph loop continuously for 72 hours? No problem.
Wasting electricity to "generate tens of thousands of lines of useless code" at will? Why is that in any way a desirable future?
One person's waste is another's value. Do you have any idea how "wasteful" tik tok or any other streaming platform is? I'll grant that AI is driving unprecedented data center development but it's far from the root cause, or even a leading clause, of our climate issues. I always find it strange that this is the first response so many have to AI, when it poses other more imminent existential threats IMO.
By Sharlin 2026-02-2320:41 It was a reply to what the GP said about running local generation 24/7 for no good reason, just because it's possible (and electricity is too cheap, apparently). There are many more threats, but those are beside the point in this specific context.
By shoobiedoo 2026-02-2319:17 The climate change alarms have been sounding for decades and yet vehicles keep getting bigger. Even in formerly "doing it right" countries like Japan. Turns out humans will always choose vanity and status symbols over facts. Oh well
A lot of code is "useless" only in the sense that no one wants to buy it and it will never find its way into an end user product. On the other hand, that same code might have enormous value for education, research, planning, exploration, simulation, testing, and so on. Being able to generate reams of "useless" code is a highly desirable future.
By Sharlin 2026-02-2320:37 Obviously "useful" doesn't just involve making money. Code that will be used for education and all of these things is clearly not useless.
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.
Optimists will imagine it to one day be as taxing and thus as wasteful as firing up MS Paint.
No that’s a stretch, but firing up a AAA game.
At least you (hopefully) get hours of entertainment from firing up an AAA game. Whereas generating vast amounts of code that you're never going to use has… some novelty value, I suppose. Luckily the novelty is going to wear off soon, I can't really see many people getting their daily happiness boost from making code machine say brrrrt straight to /dev/null. Even generating smut is a vastly more understandable (and vastly more commonplace, even now) use case for running genAI every day for hours.
By nineteen999 2026-02-2412:19 The bigger use for case for AAA games? Employment for highly talented artists, 3D modellers and sculptors, texture artists, sound and music artists, and even programmers.
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).
By embedding-shape 2026-02-2321:00 > I can't really see many people getting their daily happiness boost from making code machine say brrrrt straight to /dev/null
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?
By mikkupikku 2026-02-2411:05 Wait until you find out about video games.
I bet RAM production will only increase to meet AI demand and there will be none left for you. Or me. Or anyone. Crucial is already going probably forever and I'm sure more will follow...
By nextaccountic 2026-02-247:17 Yeah, OpenAI play was to cripple local AI "forever" (until the bubble pops), not to just deny RAM to competitors
> a relic from the days when everyone thought Drupal was the future (long time ago).
Drupal is the future. I never really used it properly, but if you fully buy into Drupal, it can do most everything without programming, and you can write plugins (extensions? whatever they're called...) to do the few things that do need programming.
> The Epilogue: That site has since been ported to WordPress, then ProcessWire, then rebuilt as a Node.js app. Word on the street is that some poor souls are currently trying to port it to Next.js.
This is the problem! Fickle halfwits mindlessly buying into whatever "next big thing" is currently fashionable. They shoulda just learned Drupal...
I'm not sure if you're serious or not, but while I never liked Drupal (even used to hate it once upon a time), I always liked the pragmatism surrounding it, reaching to the point of saving php code into the mysql database and executing from there.
> reaching to the point of saving php code into the mysql database and executing from there.
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.
By rovr138 2026-02-2318:06 There's implode() and explode() as well as serialize() and unseralize()
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.
> It burned through a mountain of tokens, but 10/10 - would generate tens of thousands of lines of useless code again.
Pardon me, and, yes, I know we're on HN, but I guess you're... rich? I imagine a single run like this probably burns through tens or hundreds of dollars. For a joke, basically.
I guess I understand why some people really like AI :-)
By patates 2026-02-2314:45 It was below 100$, but only after burning through the 20x max session limit.
By ErikBjare 2026-02-2314:46 The subsidized Codex/Claude subscriptions make it not so bad.
By otabdeveloper4 2026-02-2417:35 It's something you'd do once for shits and giggles, before realizing it's only funny once.
By pjmlp 2026-02-2314:35 There are plenty of SMEs trapped into that future. :)
By embedding-shape 2026-02-2312:107 reply Agree, and it's also such a shame that none of the AI companies actually focus on that way of using AI.
All of them are moving into the direction of "less human involved and agents do more", while what I really want is better tooling for me to work closer with AI and be better at reviewing/steering it, and be more involved. I don't want "Fire one prompt and get somewhat working code", I want a UX tailored for long sessions with back and forth, letting me leverage my skills, rather than agents trying to emulate what I already can do myself.
It was said a long time ago about computing in general, but more fitting than ever, "Augmenting the human intellect" is what we should aim for, not replacing the human intellect. IA ("Intelligence amplification") rather than AI.
But I'm guessing the target market for such tools would be much smaller, basically would require you to already understand software development, and know what you want, while all AI companies seem to target non-developers wanting to build software now. It's no-code all over again essentially.
Is it any surprise that the cocaine cartels really want you to buy more cocaine, so they don't focus on its usefulness in pain relief and they refine it and cut it with the cheapest substances that will work rather than medical-grade reagents?
Same thing.
By embedding-shape 2026-02-2312:27 It's surprising that the ones who are producing the cocaine, don't try to find the best use of the cocaine, yes. But then these are VC-fueled businesses, then it all goes out the window, unfortunately. Otherwise they'd actually focus on usefulness, not just "usage" or whatever KPI they go by and share with their investors.
LLMs are drugs because they’re addictive and sap your abilities, is it?
(or generally: “Is the cocaine cartel comparison fair or unfair?”)
By dsr_ 2026-02-240:20 LLMs are fair to compare to cocaine because while there certainly could be ethical producers who follow reasonable laws and work to develop good uses, the market is completely dominated by organizations that don't.
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.
By freeopinion 2026-02-2313:544 reply Of course there are tools focusing on this. It takes a little getting used to how prevalent it is. My editor now can anticipate the next three lines of code I intend to write complete with what values I want to feed to the function I was about to invoke. It all shows up in an autocomplete annotation for me. I just type the first two or three characters and press tab to get everything exactly how I was about to type it in--including an accurate comment worded exactly in my voice.
Is that what you mean by IA?
For example, I type "for" and my editor guesses I want to iterate over the list that is the second argument of the function for which I am currently building the body. So it offers to complete the rest of the loop condition for me. Not only did it anticipate that I am writing a for loop. It figures out what I want to iterate over, and perhaps even that I want to enumerate the iteration so I have the index and the value. Imagine if I had written a comment to explain my intent for the function before I started writing the function body. How much better could it augment my intellect?
By embedding-shape 2026-02-2314:371 reply To be honest, I'm not quite sure what the ideal UX looks like yet. The AI assisted autocomplete is too little, but the idea of saying "Build X for purpose Y" is too high-level. Maintaining Markdown documents that the AI implements, also feels too high-level, but letting the human fully drive the implementation probably again too low-level.
I'm guessing the direction I'd prefer, would be tooling built to accept and be driven by humans, but allowed to be extended/corrected by AI, or something like that, maybe.
Maybe a slight contradiction, and very wish-washy/hand-wavey, but I haven't personally quite figured out what I think would be best yet either, what the right level actually is, so probably the best I could say right now :) Sorry!
The Markdown documents can be at any level. Just keep asking the AI to break each individual step in the plan down into substeps, then ask it to implement after you review. It's great for the opposite flow too - reverse engineering from working legacy code into mid-level and high-level designs, then proposing good refactors.
By embedding-shape 2026-02-2316:00 Yes, I'm talking about a UX that could handle that for the programmer instead, as an example. Zoom out a bit :)
By eikenberry 2026-02-2319:12 I think this could be a decent interface with one addition, a way to comment on the completion being suggested. You could ask it for a different completion or to extend the completion, do something different, do a specific thing, whatever. An active way to "explain my intent" with the AI (besides leaving comments hinting at what you want) in addition to the passive completion system.
By jibal 2026-02-2317:31 Which editor?
> 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.
By Barbing 2026-02-2317:21 Still magical a few years in?
>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
By Thanemate 2026-02-2313:30 >Agree, and it's also such a shame that none of the AI companies actually focus on that way of using AI.
This is because, regardless of the current state of things, the endgame which will justify all the upfront investment is autonomous, self-improving, self-maintaining systems.
By mghackerlady 2026-02-2314:013 reply I think it was Steve Jobs who said computers should be like a bicycle for the mind, I tend to agree
By jcgrillo 2026-02-2318:11 I love this Jobs quote for two reasons:
(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
By embedding-shape 2026-02-2314:26 Yeah, Douglas Engelbart was also a huge believer in that, and I think from various stuff I've read from him and the Augmentation Research Center put me on this track of really agreeing with it.
"Bicycle for the mind", as always when it involves Jobs, sounds more fitting for the masses though, so thanks for sharing that :)
Agents are a "self-driving car for the mind". I don't enjoy or dislike driving, but lots of Americans love to drive. In the future they will lament their driving skills' decline.
We as the general population have consistently lost lots of skills from just 200 years back. Most likely we will not miss them (though coding used to be my hobby).
Though if apocalypse happens and all of our built tech goes away, we are in for a serious survival issu.
By Barrin92 2026-02-2320:36 >Most likely we will not miss them
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
By seanclayton 2026-02-2412:03 Though if ~~apocalypse~~ war happens and all of our built tech goes away, we are in for a serious survival issue.
A lot closer than you think, too
By JetSetIlly 2026-02-2320:041 reply "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 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.
Any terminal tool like Claude Code or Codex (I assume OpenCode too, but I haven't tried) can do it, by using as a prompt pretty much exactly what you wrote, and if it still wants to edit, just don't approve the tool calls.
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.
By JetSetIlly 2026-02-2320:53 "Any terminal tool like Claude Code or Codex (I assume OpenCode too, but I haven't tried) can do it, by using as a prompt pretty much exactly what you wrote, and if it still wants to edit, just don't approve the tool calls."
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.
By vunderba 2026-02-2320:30 I’m glad I’m not the only one who’s noticed these seemingly arbitrary calls to write files using the cat command instead of the native file edit capabilities of the agent.
By mikkupikku 2026-02-2411:14 Lot's of `echo "doing a thing" ; some --other command"` which then prompt the user to permit echo commands like this...
By blibble 2026-02-2314:38 > Agree, and it's also such a shame that none of the AI companies actually focus on that way of using AI.
their valuations are replaced on getting rid of you entirely, along with everyone else
the "humans can use it to increase their productivity" is an interim step
I am learning rust myself and one of the things I definetly didn't want to do was let Claude write all the code. But I needed guidance.
I decided to create a Claude skill called "teach". When I enable it, Claude never writes any code. It just gives me hints - progressively more detailed if I am stuck. Then it reviews what I write.
I am finding it very satisfying to work this way - Rust in particular is a language where there's little space to "wing it". Most language features are interlaced with each other and having an LLM supporting me helps a lot. "Let's not declare a type for this right now, we would have to deal with several lifetime issues, let's add a note to the plan and revisit this later".
By philipportner 2026-02-2315:46 FYI: Claude has output styles, one of them is called `learning`. Instead of writing the code itself, it will add `TODO(human)` and comments to explain how to. Also adds `Insights` explaining concepts to you in its output.
This link also has a comparison to Skills further down.
https://code.claude.com/docs/en/output-styles#built-in-outpu...
By dwood_dev 2026-02-2316:30 I had a bash spaghetti code script that I wrote a few years ago to handle TLS certificates(generate CSRs, bundle up trust chains, match keys to certs, etc). It was fragile, slow, extremely dependent on specific versions of OpenSSL, 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.
By giancarlostoro 2026-02-2312:033 reply This is also how some of us use Claude despite what the haters say. You dont just go “build thing” you architect, review, refine, test and build.
It's how most of us are actually going to end up using AI agents for the foreseeable future, perhaps with increasing degrees of abstraction as we move to a teams-of-agents model.
The industry hasn't come up with a simple meme-format term to explain this workflow pattern yet, so people aren't excited about it. But don't worry, we'll surely have a bullshit term for it soon, and managers everywhere will be excited. In the meantime, we can just continue doing work with these new tools.
This is an opportunity to select some stupid words that you would like to hear repeated a million times. The process is like patiently nurturing a well-contained thing, so how about "egg coding"?
By DANmode 2026-02-2319:46 How about “engineering”?
By giancarlostoro 2026-02-2313:56 I havent quite dealt with "teams of agents" yet outside of Claude Code itself spawning subagents, but I have some ideas as to how to achieve it in a meaningful way without giving a developer 10 claude code licenses, I think the real approach that makes more sense to me is to still have humans in the loop, but have their respective agents sync together and divide work towards one goal, but being able to determine which tasks are left to be worked one and tested. I do think for the foreseeable future you will need human validation for AI.
By giancarlostoro 2026-02-2313:431 reply I like "spec driven development" but I honestly don't care what you call it, just let me build things and leave me alone. :)
By newswasboring 2026-02-2314:122 reply SDD is more like a subset. There are different ways to manage context in agentic engineering
By giancarlostoro 2026-02-2317:06 I guess, I just know I force my agent to use a ticketing system like Beads (I made my own).
> SDD
Don’t do that! On a two-day-old term?!
No wonder we’re called gatekeepers.
By newswasboring 2026-02-2322:291 reply Ok jeez, calm down. I am not shouldering all of the AI discourse lol.
By DANmode 2026-02-2322:52 ^_^
By simonw 2026-02-2313:24 Yeah that's the top contender at the moment. I think it's pretty good.
https://youtu.be/JV-wY5pxXLo?si=ga-9Gg8IZfU6g8Tg
It's vibe engineering
By gnfargbl 2026-02-2321:53 This does not spark joy.
By viraptor 2026-02-2313:34 I'm not sure there's going to be a term, because there's no difference from normal, good quality engineering. You iterate on design, validate results, prioritise execution. It's just that you hand over the writing code part. It's as boring as it gets.
> how some of us
Operative word being “some”. The issue is that too many aren’t doing it that way.
> You dont just go “build thing”
Tell that to the overwhelming majority of posters discussing vibe coding, including on HN.
By danielvaughn 2026-02-2312:561 reply Sure, but they're going to be stuck writing software for yesterday's problems. As our tools become more powerful, we're going to unlock new problems and expectations that would be impossible or impractical to solve with yesterday's tooling.
By coldtea 2026-02-2314:44 >Sure, but they're going to be stuck writing software for yesterday's problems
As long as they get paid for it (or have fun, if it's a personal project), they couldn't care less about that. Tomorrow's problems are overrated.
By tonyedgecombe 2026-02-2312:54 I suppose to some extent those people have always existed. The ones who would choose the most expedient solution.
The difference now is they can get much further along.
By philipallstar 2026-02-2313:022 reply > despite what the haters say
Thinking people who disagree with you hate you or hate the thing you like is a recipe for disaster. It's much better to not love or hate things like this, and instead just observe and come to useful, outcome-based conclusions.
LLMs really do attract haters in the classic sense though. You'll find them in almost every thread on here.
By jcgrillo 2026-02-2313:43 They also attract grifters, frauds, conmen, snake oil peddlers, and every stripe of bullshit artist. I'm someone you probably would view as a hater, but I truly don't hate LLMs. I hate the lies. Projects like this are interesting, I wish there was a lot more of this and a lot less of the "trust me bro" stuff.
By rstuart4133 2026-02-2422:51 At this point, I say it attracts LLM Luddites.
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.
By giancarlostoro 2026-02-2313:462 reply Look at any HN thread that has a project that uses AI in any way, shape or form. People quickly remark that it is slop, without even reviewing the code. If that's not blind hatred of AI, I don't know what is.
There's a huge distinction between Vibe Coding, and actual software engineers using AI tooling effectively. I vibe code for fun sometimes too, nothing wrong with it, helps me figure out how the model behaves in some instances, and to push the limits of what I understand.
By mghackerlady 2026-02-2314:052 reply Vibe Coding is like porn for programmers. It probably isn't good for you, and you'd probably be better off actually doing the thing yourself, but it feels good and satisfies our desires for instant gratification
By giancarlostoro 2026-02-2314:321 reply Well, take for example, I have ideas I've had for years but no time for because by now the requirements are insane. I want to build a backend that could survive nuclear fallout type stuff. I braindump to Claude, watch it churn out my vision for the last 12 years, its insane.
There's other things too though: my ADD and my impostor syndrome don't matter to Claude, Claude just takes it all in, so as I keep brain dumping, it keeps chugging along. I don't have to worry a bout "can I really do this?" it just does it and I can focus on "what can I do to make it better" essentially.
For me it's beyond "porn coding" its basically fulfilling my vision that's been locked away for years but I've had no time to sit down and do it fully. I can tell Claude to do something, my kid comes up and asks me to go draw with them and I can actually just walk away and look at the output and refine.
By mghackerlady 2026-02-2316:42 I never said it doesn't have use cases (much like porn a lot of the arguments against are just fear mongering) just that it isn't as good as the real thing. I myself like yapping to an LLM about ideas to see how feasible they actually are before taking a crack at it
By mikkupikku 2026-02-2411:221 reply [flagged]
By philipallstar 2026-02-2419:15 Comparing bitching about vibe coding to porn is like watching porn. You come away feeling better, but you didn't engage meaningfully with anyone else.
Who's next?
By Sohcahtoa82 2026-02-2319:36 > People quickly remark that it is slop, without even reviewing the code.
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?
We keep seeing this pattern over and over as well. Despite LLM companies' almost tangible desperation to show that they can replace software engineers, the real value comes from domain experts using the tools to enhance what they're already good at.
I'd guess this is a bet on which market is more lucrative:
* 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.
By scuff3d 2026-02-242:25 I don't think they actually care if it ever materializes. They just have to sell execs on it. As long as they can the exec will sell it to their higher ups, mostly by just flat out lying about it.
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"
By staticassertion 2026-02-2313:163 reply I had a script in another language. It was node, took up >200MB of RAM that I wanted back. "claude, rewrite this in rust". 192MB of memory returned to me.
By zozbot234 2026-02-2315:03 Solving the big RAM shortage one prompt at a time.
By ricardobeat 2026-02-2316:262 reply This is sad to see. Node was originally one of the memory efficient options – it’s roots are solving the c10k problem. Mind sharing what libraries/frameworks you were using?
By staticassertion 2026-02-2320:561 reply It was an express server. I don't think c10k is particularly interesting since it mostly just involves having cooperating scheduling. Doesn't really impact flat memory overhead etc. I mean, the binary for node alone, without any libraries etc, is larger than the produced rust binary.
By ricardobeat 2026-02-2414:51 Before Node/libuv holding open connections was really expensive resource-wise, dropping that cost to <30KB per connection was massive.
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.
By shakow 2026-02-250:09 > it’s roots are solving the c10k problem
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.
By vunderba 2026-02-2320:35 I used to have a bunch of bespoke node express server utilities that I liked to keep running in the background to have access to throughout the day but 40-50mb per process adds up quickly.
I’ve been throwing codex at them and now they’ve all been rewritten in Go - cut down to about 10mb per process.
I haven’t done a ton of porting. And when I did, it was more like a reimplementation.
> 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.
By tinco 2026-02-2317:20 My company helps companies do migrations using LLM agents and rigid validations, and it is not a surprising goal. Of course most projects are not as clean as a compiler is in terms of their inputs and outputs, but our pitch to customers is that we aim to do bug-for-bug compatible migrations.
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..
By adw 2026-02-2317:29 It’s a very good way of getting LLMs to work autonomously for a long time; give it a spec and a complete test suite, shut the door; and ask it to call you when all the tests pass.
By einpoklum 2026-02-2321:05 > Coding assistants are also really great at porting from one language to the other
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.
This is the way. This exact workflow is my sweet spot.
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.
By crashabr 2026-02-2323:17 This is broadly how I worked when I was still using chat instead of cli agents for LLM support. The downside, I feel, is that unless this is a codebase / language / architecture I do not know, it feels faster to just code by hand with the AI as a reviewer rather than a writer.
your patch queue approach is very clever. Solves a huge tech debt poblem with llm code gen. Should work with jujitsu too probably.
Would be curious to see more about how you save tokens with lua too.
Do you blog?
Thanks for your interest in this work - I do not blog(maybe I should?) but i have posted a bit more on X about this work.
- 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.
I quit x so cant read beyond toplevel links. I subscribed to your tool on github, would appreciate blog-posts-in-release notes to keep up with future developments. Will try the tool. Rare to find something new among ai hype, thank you.
By hsaliak 2026-02-2414:35 Fair enough. I'll find a way to publish some of this. I try to cover most of the information in the docs/ folder, and keep it up to date. Blog posts in release notes is a good idea!
By qwm 2026-02-2418:59 I did this exact same thing for porting a compiler from one language to another with Codex. I run tests at every step, and verified that bytecode output was byte-for-byte identical. I was very impressed at the results, and this is coming from someone who's always pointing out issues with AI programming.
By codegladiator 2026-02-2314:04 > This was human-directed, not autonomous code generation.
All my vibe coded projects are human directed, unless explicitly stated otherwise
By polyterative 2026-02-2312:58 I am having immense success with the latest models developing a personal project that I open sourced and then got burned off by.I can't write anymore by hands but I do enjoy writing prompts with my voice.I have been shipping the best code the project has ever seen.The revolution is real.
By Aurornis 2026-02-2314:28 Coding assistants are great at pattern matching and pattern following. This is why it’s a good idea to point them at any examples or demos that come with the libraries you want to use, too.
By nu11ptr 2026-02-2312:32 Quite good. I ported my codebase from Go to Rust in a fraction of the time it would have taken me to rewrite it.
By xhkkffbf 2026-02-2416:10 If every AST is isomorphic, why bother? Don't you miss getting some of the advantages of Rust?
How does he solve the Fruit of the Poison Tree problem? For all he know, his LLMs included a bunch copyrighted or patented code throughout the codebase. How is he going to convince serious people that this port is not just a transformation of an _asset_ into a _liability_?
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.).
By DANmode 2026-02-2322:24 One or both of you have the story very wrong.
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…
I'm a long-time Rust fan and have no idea how to respond. I think I need a lot more info about this migration, especially since Ladybird devs have been very vocal about being "anti-rust" (I guess more anti-hype, where Rust was the hype).
I don't know if it's a good fit. Not because they're writing a browser engine in Rust (good), but because Ladybird praises CPP/Swift currently and have no idea what the contributor's stance is.
At least contributing will be a lot nicer from my end, because my PR's to Ladybird have been bad due to having no CPP experience. I had no idea what I was doing.
> I guess more anti-hype, where Rust was the hype
Yeah that is the thing I struggle with. I am really happy for people falling in love with Rust. It is a amazing language when used for the right use case.
The problem is that had my Rust adventures a few years ago and I am over the hype cycle and able to see both the advantages and disadvantages. Plus being generally older and hopefully wiser I don't tie my identity towards any specific programming language that much.
So sometimes when some Junior dev discovers Rust and they get really obnoxious with their evangelicalism it can be very off putting. Really not sure how to solve it. It is good when people get excited about a language. It just can be very annoying for everyone else sometimes.
By geertj 2026-02-2317:37 > 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.
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).
By bjackman 2026-02-240:26 I find the attitude of the Ladybird devs refreshing though, and it kinda aligns with my opinions about Rust.
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".
By akst 2026-02-241:47 The whole obnoxious dogmatic evangelicalism thing is definitely a wider human phenomenon outside software and junior devs picking up new languages.
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.
By virgil_disgr4ce 2026-02-2317:482 reply I'm contemplating diving into Rust for a smallish project, a daemon with super-basic UI intended for Linux, MacOS and Windows. Do you mind expanding on what disadvantages you encountered? Or use-cases that aren't appropriate for Rust?
It's all the stuff that people always mention; they are not wrong. You spend a decent amount of time... conversing with the compiler about lifetimes and, in my experience, even more so about the type system, which is _extremely_ complicated. But you also have to keep in mind that Rust got very popular, very fast, and the tail end of something like that is always a negative reaction. The language is the same, despite the hype roller coaster.
By LoganDark 2026-02-2320:53 I find Rust's complexity freeing, in that there are often at least a few ways to express what I want, and I can choose the one I feel best fits the use-case and my desired ergonomics. (I also like that there are often ways to express exactly a very precise want, owing well to the Rust principle of "zero-cost abstractions.") However of course, that very same complexity can make it unclear which approach may best serve a given objective, and lead to false starts, wacky implementations, or even giving up entirely.
By cmrdporcupine 2026-02-2318:373 reply I'm not OP but here's my disadvantages. Rust is the way I earn my living, and also my open source tool of choice. And my background is 25 years of SWE career:
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.
By staticassertion 2026-02-244:16 First 2 are very legit, as a rust dev myself. I wish Rust had a larger stdlib and every argument against it leaves me pretty unconvinced/ feeling like the arguments could just as easily leave us to believe that "HashMap" should not be included (some people believe this), or even "time" should not be, etc.
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.
By metaltyphoon 2026-02-2323:211 reply > often with duplicated functionality (multiple Base64, rand, sha256, etc crates)
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.
I don't think they mean multiple versions of the same crate (although can certainly happen too), but rather multiple different crates that cover the same functionality.
By cmrdporcupine 2026-02-242:25 this
tho duplicated crates with different major versions through transitive deps is also i believe possible
By cmrdporcupine 2026-02-2320:561 reply Sure, and I'm available to provide balance commentary for hire, too ;-)
By jacquesm 2026-02-2321:03 I'm pretty sure you wouldn't like to work on what I'm working on right now though!
By renewiltord 2026-02-2318:152 reply [flagged]
By swiftcoder 2026-02-249:56 > every ten seconds someone will start asking to tax everyone to fund Rust Software Foundation or constantly argue that you have to donate a percentage of income to it
I have literally never heard this, in ~decade of working with Rust. I think you may be taking some random mailing list discussions a little too seriously
By staticassertion 2026-02-244:19 I've been writing rust for over a decade and I've been quite active in the community at times. I've barely even heard of the rust foundation, let alone seen suggestions to donate.
By Onavo 2026-02-2316:54 > So sometimes when some Junior dev discovers Rust and they get really obnoxious with their evangelicalism it can be very off putting.
And experience doesn't equal correct decision making. People just get traumatized in different ways.
By shevy-java 2026-02-2319:521 reply They are moving fast.
Next month it will be yet-another-language.
Eventually they come full circle and settle for either C or C++.
By Perz1val 2026-02-2321:13 They've been stuck with swift adoption for a long time, abandoning that was the reasonable decision. That only leaves Rust as the second language to C++
By ramon156 2026-02-2312:51 I guess I missed this, thanks!
By thrdbndndn 2026-02-2313:192 reply I'd argue Ladybird itself is a "hype" project.
Anything trying to break the browser monopolies in a meaningful way deserves the hype, IMO.
By andrekandre 2026-02-2618:02
sorry to be pedantic but, do you mean perhaps oligopolies? and by that do you mean marketshare or technology share? i'm just curious what people are looking for in ladybird (just better tech or better or governance?)> monopolies
By throwaway2037 2026-02-2313:282 reply Fair point. What does Ladybird need to achieve in your opinion to shake the "hype" label? Honestly, I, myself, don't have a good answer!
By thrdbndndn 2026-02-2314:552 reply To me, a project's "hype-ness" is the ratio of how much attention it gets over how useful it actually is to users.
As a browser, Ladybird usefulness is currently quite limited for obvious reasons. This is not meant to dismiss its achievements, nor to overlook the fact that building a truly useful browser for everyday users is something few open source teams can accomplish without the backing of a billion dollar company. Still, in its present state, its practical utility remains limited.
By JumpCrisscross 2026-02-248:011 reply > As a browser, Ladybird usefulness is currently quite limited for obvious reasons
By this definition all basic research is hype.
No, not necessarily. It's the ratio and for most basic research the numerator of the fraction is also approaching zero.
By JumpCrisscross 2026-02-2411:22 Yes, necessarily. Basic research is currently useless in the same way building something that hasn’t been built is currently useless.
By shevy-java 2026-02-2319:54 Good verdict. I agree.
Ladybird will have to deliver eventually - on this part I think many people agree with.
By pelagicAustral 2026-02-2313:372 reply > What does Ladybird need to achieve in your opinion to shake the "hype" label?
A release (?)
Its possible to dislike Rust but pragmatically use it. Personally, I do not like Rust, but it is the best available choice for some work and personal stuff.
By shevy-java 2026-02-2319:542 reply I think this is a good, realistic point of view.
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.
By zarzavat 2026-02-2321:59 Honestly I find writing Rust more fun than writing Python. Python just doesn't scale, any non-trivial quantity of it has a habit of turning into spaghetti however hard I try to be disciplined.
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.
By voxelghost 2026-02-242:08 Definetly, thats how I have felt about and used C++ for most of my career. ( well except I dont select C++ for personal projects).
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.
By Levitating 2026-02-2319:451 reply So what don't you like about it?
By accelbred 2026-02-2320:26 Its for the time being is stuck with LLVM, so I can't currently LTO with GCC objects. Its got a lot higher complexity than I perfer in a language. A lot of features I find important seem perma-unstable. Pin is unnessesarily confusing. No easy way to define multiple compilation units for use with linker object selection and attribute constructor. The easy path is downloading binary toolchains with rustup and not using your disto package manager. You can't use unstable features without the bootstrap env var on distro rust toolchains. Cargo leads to dependency bloat. The std/core crates are prebuilt binaries and bloat binary sizes. Bindgen doesn't translate static inline code. The language has a ton of stuff it exposes just to std and not user code. Unsafe code is unergonomic. No easy way to model a cleanup function that needs more args. No support for returns_twice. No ability to use newer stuff like preserve_none. Can't go-to-definition from a bindgen binding to original header file. Macros pollute global namespace. Can't account for platforms where size_t and uintptr_t are different. Traits can only be relied on if marked unsafe. Can't implement something like defer since it holds a borrow. no_std code still can pull in core::fmt. Can't enforce dependencies are also no_std. Panics are considered safe. No way to add non-function fields to dyn vtables. No way to declare code separately from definition. No way to have duplicate type definitions that merge, making interop between different bindgen generated modules annoying.
I am somewhat concerned about the volatility. All three languages have their merits and each has a stable foundation that has been developed and established over many years. The fact that the programming language has been “changed” within a short period of time, or rather that the direction has been altered, does not inspire confidence in the overall continuity of Ladybird's design decisions.
By 0x00cl 2026-02-2313:35 Ladybird as a project is not that old, and it's still in pre-alpha, if they are going to make important changes then it's better now than later.
> I am somewhat concerned about the volatility.
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.
they tried swift, it didn't work, and they figured rust was the best remaining option. that's not "flip-flopping" (by which I assume you mean random indecisiveness that leads to them changing their mind for no reason)
By lioeters 2026-02-2319:04 Yup, this was not flip-flopping, it was willingness to be open to options, even if it means going back on a decision branch made earlier in the process.
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.
By qingcharles 2026-02-2318:52 They made a very pragmatic and sensible decision after reviewing Swift that it wouldn't be suitable for their purposes, so they shifted to the next best alternative. I think they reasoned it very well and made a great decision.
By 0x457 2026-02-2320:00 I guess they bet on Swift being more than Apple's blessed way of writing UI software.
By fmajid 2026-02-2315:50 It's not that they are loving Rust, but they realized going all-in on Swift means becoming sharecroppers on massa Tim Apple's plantation.
There's been some fun volatility with the author over the years. I told him once that he might want to consider another language to which he replied slightly insultingly. Then he tried to write another language. Then he tried to switch from C++ to Swift, and now to Rust :P
Indeed, and as a school those 18 months are well worth it, but it is in many ways also 18 months wasted. There is a strong sense of NIH with the Ladybird dev(s), and I wonder if that isn't their whole reason for doing this.
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.
By andrekandre 2026-02-2618:15
the thing for me is (and maybe i've missed something?) but if after 18 months of struggle i'd really like to get a more insightful blog post* that goes into detail about what exactly failed and the process that lead to it... as a language enthusiast i think getting valuable lessons/reflections would be cool (was the cause swift c++ iterop progressing too slow? or some other technical hurdle? was there politics involved? etc etc)> 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 ^^
The sense of NIH is from Serenity, and that was probably the reason for Jakt's existence too. Now it's spun off into its own project there is a lot more pragmatism.
Well, here's to hoping because we really need a stand-in for FF. I realize the irony here in terms of that being the ultimate 'NIH' project but that one I can get behind because the browser landscape is much too fragile. Of course they might end up taking users away from FF rather than from Chrome, Edge or Safari.
By rjh29 2026-02-2323:20 In case you didn't know they're using a lot of third-party libraries now for pretty major things: libcurl for http, Skia/Harfbuzz for rendering, libxml, OpenSSL, ffmpeg, etc:
https://github.com/LadybirdBrowser/ladybird/tree/8017f8a7ed3...
The core browser engine, JS/CSS/layout etc will always be original.
> I think I need a lot more info about this migration
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.
By tvshtr 2026-02-2322:31 This makes sense because GUI wise Rust isn't really here yet (but it's close).
By dougiejones 2026-02-2312:381 reply TFA mentions "the contributor's" stance on Swift.
But not the stance on Rust, which is something I'm wondering. I understand there's a core team assigned, but are the ~200 contributors okay with this migration?
By the_mitsuhiko 2026-02-2314:031 reply Why would 200 contributors have to be okay with this migration? The project has a leader, the leader makes decisions.
because let's say 150 contributors might not be okay with the decision and leave. hard to lead from the front if there is nobody behind to be lead.
By swiftcoder 2026-02-2319:091 reply To be fair, any of them who didn't leave in the last few controversies probably won't leave over this.
By 0x457 2026-02-2320:11 "I can excuse foaming over pronouns and master branch, but I draw a line at using rust" Would not be surprised by that opinion.
The public announcement was less then a week ago. Meanwhile in TFA:
> ... the entire port took about two weeks.
So he was ~halfway in when he made the Swift announcement.
By hackpelican 2026-02-2315:321 reply Doesn’t sound like a bad thing to evaluate the most obvious alternative to build confidence before officially pulling the plug.
The most obvious alternative would be Zig. I don't see any Swift adoption outside the Apple ecosystem.
By hypeatei 2026-02-2316:19 Swift adoption had been dead long before the actual announcement. It's likely Rust was being considered long before this two week experiment with LLMs.
it's very odd that someone with no experience would take a big project like this and just jump to another language because he trusts the AI generated code of current models
if it works it works i guess, but it seems mad to me on the surface
Why do you think the creator behind SerenityOS has no experience? I mean it’s not the most popular OS out there but he seems like a capable individual.
in case it's not glaringly obvious from the comment, he has plenty of cpp experience and little rust experience, and that's according to his own comments
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"
By jacquesm 2026-02-2321:00 Indeed, the hard part won't the port, but the maintenance of that which got ported. To be fair though, he's probably going to be able to use the same techniques for that.
By simonask 2026-02-2317:32 It's hard to articulate, but as someone who knows first hand, I just want to say that manic productivity is not the same as solid engineering.
I did, and the point stands because reading someone else's code is not the same as writing it, esp. when you're not able to do so to the same standard
Non sequitur. Again, no trust was involved, only verification through extreme testing.
Also, as others have pointed out, "someone with no experience" simply isn't true.
the trust element to me is jumping into a port, not specific code although code you didn't write in a language you're not an expert with, will ALWAYS introduce an added risk of falling into pitfalls you can only avoid with experience, the more the merrier
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
> code you didn't write
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 write 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
By jibal 2026-02-2419:28 "It" was the C++ code ... you don't even understand what you yourself wrote.
> 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.
By swiftcoder 2026-02-2319:04 > especially since Ladybird devs have been very vocal about being "anti-rust" (I guess more anti-hype, where Rust was the hype).
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)
