Cool, that seems like a rational choice. I hope this will help Ladybird and Servo benefit from each other in the long run, and will make both of them more likely to succeed
Definitely, would be great to see a Servo-based Ladybird.
Ladybird adopts Rust, with help from AI
641–650 of 731 posts
Re: Ladybird adopts Rust, with help from AI
#642Cool, that seems like a rational choice. I hope this will help Ladybird and Servo benefit from each other in the long run, and will make both of them more likely to succeed
I hope it does not -> because we don't more browser crossbreeding
Small browsers need to unite if they ever hope to become relevant.
Re: Ladybird adopts Rust, with help from AI
#643Earlier quoted context omitted.
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…
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 reali…
I feel compilation time is unbearable in Rust, even on MacBook pro M3 max, don't get me started on space
Re: Ladybird adopts Rust, with help from AI
#644This byte for byte output is the right way to go. But it depends on test cases. Hope the amount of cases cover all possible combination of input
Re: Ladybird adopts Rust, with help from AI
#645Earlier quoted context omitted.
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-pa…
Cool thanks.
Re: Ladybird adopts Rust, with help from AI
#646[flagged]
Re: Ladybird adopts Rust, with help from AI
#647> 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.
Does this still get you most of the memory-safety benefits of using Rust vs C++?
Re: Ladybird adopts Rust, with help from AI
#648> We know the result isn’t idiomatic Rust, and there’s a lot that can be simplified once we’re comfortable retiring the C++ pipeline. That cleanup will come in time. Correct me if I’m wrong since I don’t know these two languages, but like some other languages, doing things the idiomatic way could be dramatically different. Is “cleanup” doing a lot of heavy lifting here? Could that also mean another complete rewrite f…
This is the famous trap that Joel on Software talked about in a blog post long time ago. If you do a rewrite you essentially put everything else on halt while rewriting. If you keep doing feature dev on the old while another "tiger team" is doing the rewrite port then these two teams are essentially in a race against each other and the port will likely never catch up. (Depending on relative velocities) Maybe they thi…
The context matters when we talk about Joel's article[0].
It's about Netscape. By the time, Netscape had dominated the browser market. It was the leader and that means they had all the market share to lose. You can bet Microsoft's decision makers were very closely monitoring what those at Netscape were doing.
Today, practically nobody uses Ladybird. No one even knows it[1]. It's so behind and has nothing to lose. If you really want to rewrite, it's better to do it when you have nothing to lose.
[0]: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
[1]: to quote Joel, "no one" means less than one million people.
Re: Ladybird adopts Rust, with help from AI
#649"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." I'm confused about this part. What part of the browser did they want GC and inheritance for? I'd get it if they were writing the UI in this, but the rest of this post is about the JS engine. They weren't going to 1:1 map JS objects…
Lot of DOM APIs are like that. You have methods like element.[parent|children]() which implies circular structure, and then you have APIs like element.click(), which emits a click event that bubbles through the DOM - which means that element has to have some mutable reference to the DOM state. Or even element.remove(), which seems like a super weird api to have on an element of a collection, from Rust API design point of view.
You can model these with reference counting, but this turned out unfeasible in browsers. There's a great talk from when Blink (Chrome) transitioned from reference counting to GC, which provides a lot more details about these problems in practice: https://www.youtube.com/watch?v=_uxmEyd6uxo
> I'd get it if they were writing the UI in this, but the rest of this post is about the JS engine.
I think this might be the reason they started with the JS engine and not with some more fundamental browser structures. JS object model has these problems, too, but the engine has to solve them in more generic way. All JS objects can just be modeled as some JSObject class/struct where this is handled on the engine level.
DOM and other browser structures are different because the engine has to understand them, so the browser developers have to interact with the GC manually and if you watch the talk above, you'll see that it's quite involved to do even in C++, let alone in Rust, which puts a bunch of restrictions on top of that.
Re: Ladybird adopts Rust, with help from AI
#650Earlier quoted context omitted.
> 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…
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...
Yeah, OpenAI play was to cripple local AI "forever" (until the bubble pops), not to just deny RAM to competitors