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

701–710 of 731 posts

Re: Ladybird adopts Rust, with help from AI

#701

Post by CuriouslyC »

sobani wrote: post #683
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.…

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.

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

Re: Ladybird adopts Rust, with help from AI

#702

Post by nyarlathotep_ »

(Un?)ironically enough, Mr Kling was one of the people that (indirectly) first got my attention wrt LLM coding.

I watched some of his streams on the development of the JIT compiler (what this change set seems to replace) on one of his streams, and was blown away by the quality of Copilot generated suggestions/completions on an (under-represented) domain (x86 opcodes, etc). This was before Claude Code et al, and pretty early-on for LLM tooling.

Re: Ladybird adopts Rust, with help from AI

#703

Post by hsaliak »

tarasglek wrote: post #633
hsaliak wrote: post #494

Earlier quoted context omitted.

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…

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.

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!

Re: Ladybird adopts Rust, with help from AI

#704

Post by pornel »

troad wrote: post #692
pornel wrote: post #541

Earlier quoted context omitted.

Strong disagree. Rust copied C++ syntax to avoid looking weird to C++ programmers, but the similarity is skin deep. C can be tamed, because it's mostly a subset of Rust, but C++ idioms are a death from papercuts. OOP, weakly-typed templates, and mutable aliasing create impedance mismatch in almost every C++ API. Rust doesn't have data inheritance, and what looks like interface inheritance is merely extra requirements…

As someone who's worked in both C++ and Rust, they're deeply similar languages. There are far more exotic languages out there. APL. Erlang. Forth. In the grander scheme of things, Java and C# are literally the same language, Rust and C++ are twins, C is their dad, Forth is the owl staring through the dining room window, and Erlang is an alien spaceship passing over the house.

I've been writing Rust since 0.x versions.

> C is their dad

You can write "C with classes" in the "C/C++/Rust" language, and have users of all three tell you you're doing it wrong. The commonalities between them are mostly necessities of systems programming, FFI, and LLVM-style optimizations, but they all try to get there in different ways.

> There are far more exotic languages out there. APL. Erlang. Forth

Early Rust started as an Erlang clone, with task supervision trees and all (panics, lock poisoning, and the defunct UnwindSafe trait are vestigial features from that experiment).

Rust has more in common with Ocaml than C or C++. It's not a C family language, it just took C-like syntax to avoid the stigma of being "exotic" like the languages that inspired it.

Rust did copy move semantics from C++, but even that ended up being different enough to be incompatible with basic C++ design patterns. Rust chose to have only trivially movable types and guarantee absence of move constructors, so it can't even safely pass a C++ std::string.

Re: Ladybird adopts Rust, with help from AI

#705

Post by ricardobeat »

staticassertion wrote: post #500
ricardobeat wrote: post #324

Earlier quoted context omitted.

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?

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.

Before Node/libuv holding open connections was really expensive resource-wise, dropping that cost to 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.

Re: Ladybird adopts Rust, with help from AI

#706

Post by troad »

pornel wrote: post #704
troad wrote: post #692

Earlier quoted context omitted.

As someone who's worked in both C++ and Rust, they're deeply similar languages. There are far more exotic languages out there. APL. Erlang. Forth. In the grander scheme of things, Java and C# are literally the same language, Rust and C++ are twins, C is their dad, Forth is the owl staring through the dining room window, and Erlang is an alien spaceship passing over the house.

I've been writing Rust since 0.x versions. > C is their dad You can write "C with classes" in the "C/C++/Rust" language, and have users of all three tell you you're doing it wrong. The commonalities between them are mostly necessities of systems programming, FFI, and LLVM-style optimizations, but they all try to get there in different ways. > There are far more exotic languages out there. APL. Erlang. Forth Early Rus…

> It's not a C family language, it just took C-like syntax to avoid the stigma of being "exotic" like the languages that inspired it.

I agree that Rust has very conventional C-like syntax, but I'd go further and say it has fairly conventional C-like semantics too, at least in its current iteration. I think you could safely duck type Rust itself as a C-like. :)

Strong agree that Rust has drawn great inspiration from the ML family by way of OCaml. Rust is a C-like with ML characteristics, which are its greatest quality, imho. On the other hand, I don't think there's much trace of Erlang left in Rust -- there's probably more Erlang in Go than Rust, and Go is squarely a C-like.

I think it's fair to say that Rust started out more exotic than it is now, but perhaps all that safe, C-like syntax has led to convergent evolution towards other C-likes?

> Rust did copy move semantics from C++, but even that ended up being different enough to be incompatible with basic C++ design patterns. Rust chose to have only trivially movable types and guarantee absence of move constructors, so it can't even safely pass a C++ std::string.

Right, but compare all of that to Erlang's actor-based message passing, where mandatory immutability averts the need to move or lock anything at all, and I think it's clear why one would group Rust with C++, and not Erlang.

Re: Ladybird adopts Rust, with help from AI

#707

Post by andsoitis »

yreg wrote: post #697
andsoitis wrote: post #694

> We will continue developing the engine in C++, and porting subsystems to Rust will be a sidetrack that runs for a long time. So, even though they want the code base to be in Rust, they will continue writing new code in C++ and then translating it to Rust later to remove the C++ they just added. There must be a really good reason for this, such as Rust doesn’t interop well with C++, otherwise this seems like a poor…

Isn't the reason simply that they want to code in C++? This is a passion project.

> Isn't the reason simply that they want to code in C++?

I don't know that that is the reason, given the opening lines of the article:

We’ve been searching for a memory-safe programming language to replace C++ in Ladybird for a while now. We previously explored Swift, but the C++ interop never quite got there, and platform support outside the Apple ecosystem was limited. Rust is a different story. The ecosystem is far more mature for systems programming, and many of our contributors already know the language. Going forward, we are rewriting parts of Ladybird in Rust.

Re: Ladybird adopts Rust, with help from AI

#708

Post by surajrmal »

NoboruWataya wrote: post #489
surajrmal wrote: post #248

Earlier quoted context omitted.

Note that Firefox doesn't have market dominance. It is under 5% market share. That said I imagine Firefox users to be the most likely to make the jump. However, the web is a minefield of corner cases. It's hard to believe it will be enough to make the browser largely useful enough to be a daily driver.

Why do you think Firefox users would be most likely to make the jump? The main reason I see people give for supporting Ladybird is challenging the dominance of the incumbents. That's not really a great reason to switch from Firefox because, as you note, it doesn't have any dominance. And there's also an argument that splitting the non-Chrome market into two only increases Chrome's dominance. From what I can tell from…

Arguably anyone not using Chrome, safari or edge is the most likely to try Ladybird.

Re: Ladybird adopts Rust, with help from AI

#709

Post by xhkkffbf »

skerit wrote: post #15

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

If every AST is isomorphic, why bother? Don't you miss getting some of the advantages of Rust?

Re: Ladybird adopts Rust, with help from AI

#710

Post by surajrmal »

rq1 wrote: post #673
surajrmal wrote: post #190

Earlier quoted context omitted.

It depends. I migrated a 20k loc c++ project to rust via AI recently and I would say it did so pretty well. There is no unsafe or raw pointer usage. It did add Rc > wasn't very difficult, but keeping the code structure identical at first allowed us to continue to work on the c++ code while the rust port was ongoing and keep the rust port aligned without needing to implement the features twice. I would say modern c++…

> I would say modern c++ written by someone already familiar with rust will probably be structured in a way that's extremely easy to port because you end up modeling the borrow checker in your brain. I can't stress out how much important this sentence is. I would even remove the "familiar with rust" part. Anyone who still thinks it's good to use C/CPP on modern hardware where Rust support is available and good: pleas…

The reason folks still use c/c++ is because of ecosystem. Chances are you have a lot of code you depend on and don't have straightforward ways to port it (and all the transitive deps). Especially in the case of larger enterprise software where there are 10s of millions of lines keeping you entrenched. Foundational things like your threading model, async executor, etc can make it difficult. If you're operating in a micro service environment and your core does are both minimal and ported, the journey becomes much more tractable.
Post reply on HN