Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ladybird adopts Rust, with help from AI

ladybird.org

Post reply on HN
Print view View original

581–590 of 731 posts

Re: Ladybird adopts Rust, with help from AI

#581

Post by yc-kraln »

josephg wrote: post #95
patates wrote: post #68

Earlier quoted context omitted.

> 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 permissi…

> 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 ever…

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?

Re: Ladybird adopts Rust, with help from AI

#582

Post by josephg »

mjrpes wrote: post #555
josephg wrote: post #95

Earlier quoted context omitted.

> 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 ever…

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.

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.

Re: Ladybird adopts Rust, with help from AI

#583

Post by nicoburns »

metaltyphoon wrote: post #574
cmrdporcupine wrote: post #400

Earlier quoted context omitted.

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 re…

> 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.

Re: Ladybird adopts Rust, with help from AI

#584

Post by godelski »

jp1016 wrote: post #300

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.…

  > Way too many rewrites fail because people try to "improve" things during the port
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*.

I think the last one gets ignored easily but my favorite time to document code is when reading it (but the best time is when writing it). It forces you to think explicitly about what the code is doing and makes it harder for the little things to slip by. Given that Ladybird is a popular project I really do think good documentation is a way to accelerate its development. Good documentation means new people can come in and contribute faster and with fewer errors. It lowers the barrier to entry, substantially. It's also helpful for all the mere mortals who forget things

Re: Ladybird adopts Rust, with help from AI

#585

Post by josephg »

grey-area wrote: post #570
josephg wrote: post #552

Earlier quoted context omitted.

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 bro…

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).

Re: Ladybird adopts Rust, with help from AI

#586

Post by robryan »

fmajid wrote: post #295
hackpelican wrote: post #283

Earlier quoted context omitted.

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.

The key requirement is memory safety, which would rule out Zig.

Re: Ladybird adopts Rust, with help from AI

#587

Post by tapstapstaps »

josephg wrote: post #95
patates wrote: post #68

Earlier quoted context omitted.

> 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 permissi…

> 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 ever…

[dead]

Re: Ladybird adopts Rust, with help from AI

#588

Post by chupchap »

jp1016 wrote: post #300

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.…

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...

Re: Ladybird adopts Rust, with help from AI

#589

Post by josephg »

easterncalculus wrote: post #573
metabeard wrote: post #119

Earlier quoted context omitted.

Please post this. I'd love to play with it and, especially, see how fast it is.

Seconding this comment, as someone who loves JMAP.

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:

    server.listener.http.permissive-cors = true
or

    server.listener.https.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.

Re: Ladybird adopts Rust, with help from AI

#590

Post by mr_mitm »

srcreigh wrote: post #437
mr_mitm wrote: post #131

Earlier quoted context omitted.

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. https://github.com/AdrianVollmer/FluxFeed

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.

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.
Post reply on HN