521–530 of 731 posts
This is really YOLOing as the original author doesn't know Rust well so what happens if they hit some complex production issue LLM aren't aware of? Hiring an expensive consultant to fix that until the next LLM iteration?
they learn Rust
it takes a couple of years
it's not that hard.
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.…
> 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…
Exactly my thought! I guess I'll keep Firefox for the foreseeable future...
> After the initial translation, I ran multiple passes of adversarial review, asking different models to analyze the code for mistakes and bad patterns. I feel like you just know it’s doomed. What this is saying is “I didn’t want to and cannot review the code it generated” asking models to find mistakes never works for me. It’ll find obvious patterns, a tendency towards security mistakes, but not deep logical errors.
Somehow they did use this as part of their approach to get to 0 regressions across 65k tests + no performance regressions though + identical output for AST and bytecode though. How much manual review was part of the hundreds of rounds of prompt steering is not stated, but I don't think it's possible to say it couldn't find any deep logical errors along the way and still achieve those results. The part that concerns m…
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
Earlier quoted context omitted.
It doesn't have to all-or-nothing. Firefox has been a mixed C++ and Rust codebase for years now. It isn't like the code is written twice. The C++ components are written in C++, and the Rust components are written in Rust. I suspect that'll also be what happens here. And if the use of Rust is successful, then over time more components may switch over to Rust. But each component will only ever be in one language at a t…
You can't compare the choices made to evolve a >20 years old codebase with a brand new one. Firefox also as Rust support for XPCOM components, so you can use and write them in Rust without manual FFI (this comes with some baggage of course). The Ladybird devs painted themselves in a corner when choosing C++ for a new web browser, with many anti-Rust folks claiming that "modern C++ was safe". Well...
Perhaps, but in fairness the project was started in 2018 when Rust was still new and unproven.
> You can't compare the choices made to evolve a >20 years old codebase with a brand new one.
I guess not, but I'm pretty optimistic about Ladybird's ability to adopt Rust if they want to. It's a much smaller codebase than Firefox (~650K LoC).
This initial PR is already ~25k LoC, so approximately 4% of the codebase. It took 1 person 2 weeks to complete. If you extrapolate from that, it would take 1 person-year to port the whole thing, which is not so bad considering that you could spread that work out over multiple years and multiple people.
And Firefox has shown that the intermediate state where you have a mix of languages is viable over the long term, even in a much larger and more complex codebase.
Earlier quoted context omitted.
It doesn't have to all-or-nothing. Firefox has been a mixed C++ and Rust codebase for years now. It isn't like the code is written twice. The C++ components are written in C++, and the Rust components are written in Rust. I suspect that'll also be what happens here. And if the use of Rust is successful, then over time more components may switch over to Rust. But each component will only ever be in one language at a t…
Firefox was special in that Mozilla created Rust to build Servo and then backported parts of Servo to Firefox and ultimately stopped building Servo. Thankfully Servo has picked up speed again and if one wants a Rust based browser engine what better choice than the one the language was built to enable? https://servo.org/
But I'm also cheering along Ladybird's progress. There's definitely room for more than one project in the space. And IMO the more browsers being built in Rust in the better.
This is really YOLOing as the original author doesn't know Rust well so what happens if they hit some complex production issue LLM aren't aware of? Hiring an expensive consultant to fix that until the next LLM iteration?
Earlier quoted context omitted.
UPDATE: tried compiling stalwart on my machine, and it took 14 minutes, with a really weird timing profile: - 99% of the ~700 crates were done compiling in about a minute or 2 - RocksDB (a C++ dependency) was 2 minutes by itself - And then it took 10 minutes (ten!) just for the final binary at the end. That's not normal for Rust code at all. Even large ones like Servo or Rustc or Zed. UPDATE2: turns out they have LTO…
Disabling codegen units = 1 speeds up the compilation further. But it’s still too many dependencies and too slow. The binary is pretty huge too.
I definitely agree that it's too slow. I just don't think the cause is "too many dependencies" because I've compiled Rust codebases with twice as many dependencies in half the time!
It seems to produce a 94MB binary. So it may be partly that there are some very big dependencies. But the amount of compilation time that ends up in the top-level crate (even with LTO disabled) also makes me feel like this must be triggering a compiler bug. Either that or using far too many generics.
Earlier quoted context omitted.
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
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.