Hacker News Reader

Comment by edgyquant | Hacker News Reader

Would also be interested to hear why. Personally I used to watch serenityOS and only recently relooked into it to see the main guy was no longer leading it but working on ladybird full time

View on HN

They announced they are doing an AI assisted rewrite of parts of their code into Rust. That would alienate some.

https://ladybird.org/posts/adopting-rust/

Myself, my annoyance with Ladybird is that restarted everything from scratch. There are components of servo that are really good and basically complete. Why not use those components and concentrate on the components where you have design conflicts with Servo?

Didn't they start with like C++, then zig, and now rust.

To me it's just not serious. They also had articles of "why we are doing zig and not rust".

It's an ambitious project, but I can't take it seriously when the tech stack is in constant flux.

I think they used swift instead of zig because Kling was using mac for development

Their origins are in C++, which is what SerenityOS has used. They've never done zig. They explored using Swift as a C++ successor language for the project[1], but seeing the platform support out of Apple was lacking, they gave up and made the bet on Rust[2].

The motivation to use a memory safe language as the alpha approaches sounds more of a longer term bet [3].

[1] https://ladybird.org/newsletter/2024-11-30/#swift-language-a...

[2] https://ladybird.org/posts/adopting-rust/

[3] https://ladybird.org/posts/changing-how-we-develop-ladybird/

They did start with C++. They experimented with Swift, then experimented with Rust, ultimately choosing Rust. I don't see how experimenting with things makes anything "not serious". If you don't question your primitives and just accept them "because that's how it has always been", you're not a very good engineer in my book. In any case, the tech stack is not in constant flux as you claim, it's still C++, with more and more parts moving / being started in Rust, with the eventual probability of Rust replacing C++ organically, I suppose. Seems like pretty sound strategy to me to slowly, but surely, adopt a memory-safe language.

I'm curious why you care about whether or not they spent time and effort to write those components themselves. Isn't that their choice as the authors? How does it materially affect you or the product experience? From my vantage point, I love the idea of having even more options as it will create competition, making all sides better for it. Having a singular dominant player in any space (whether it's a browser, kernel, or library) is something we should try to avoid whenever possible.

Spreading oneself too thin makes you much less likely to succeed.

They can obviously do whatever they want, but realistically, having five different engines that are all 70% complete is not helpful. That's not providing more options. Instead, having one that's 99% complete would be providing more options.

An AI-assisted rewrite can make sense, if you take the time to uphold semantics and code quality, as they suggested. In practice, the first file I looked in had unsound unsafe – in the Rust sense, that a safe caller could cause UB, not that any callers do so – in fact there are no callers, the functionality was removed from the C++ bindings in a 1400-file changeset but left in the associated Rust module.

Reply on news.ycombinator.com