but i still love rust ofc
There's incremental compilation cache that generates lots of churn (although Rust's compilation unit is a crate, "queries" in the compiler are cached individually, creating many cache entries per function per type).
The other half of the disk space is debug info, because abstractions that optimize down to zero runtime code still carry all of their source-level debug info.
These can be adjusted in build profiles if you're ok with coarser debug info or less fine-grained caching.
https://blog.rust-lang.org/inside-rust/2026/08/18/reducing-t...
When I mentioned, after C++26 failed its vote, that maybe they should use this extra time to focus more on memory safety, I got downvoted instead.
Surely that attitude isn't helping their situation.
I didn't downvote you (that's not something I do) but I didn't find your comment particularly relevant or on topic. This disapproval thing and working on memory safety don't seem related at all. Someone told you they had the impression that you were pushing for Rust without mentioning it. Your comment might have felt like you were backseat driving as well. More memory safety in C++ would be cool, but do you have actual ideas on how to achieve this? There are a lot of reasons people could have downvoted you.
You shouldn't worry too much about it though, just relax and forget about it. It's fine. Happens to the best of us.
Two or so ABI breaks with a few years between them also seem quite survivable.
With rust, those class of errors are very difficult to arrive at, unless you specifically make it so.
with rust, the "risk" gets moved from runtime to compiletime. I'll take a 1TB build bloat over code crashing in prod. any day.
- Making sure you compile with as few profiles as possible.
- Disabling debug info (or setting it to "line-table-only") for the default profile.
I just think agents benefit a lot from having unavoidable feedback in the dev loop, and Rust affords that through its strictness. It's easier for agents to fall into the pit of success with Rust. I do think it's somewhat lacking in compile-time features, though.
https://github.com/LadybirdBrowser/ladybird/blob/master/Docu...
Very exciting to watch a completely new browser/browser engine come together. Reminds me of the early days of Mozilla and Gecko
Posted with Ladybird :)
Even if a future AI can drive web browser development completely autonomously, I suspect it will take a huge amount of real-world time because that's just the shape of the work no matter how "smart" you are.
So you're not going to get to "build me an original web browser from scratch, make no mistakes" and get a new app the next morning or even next week, I don't think.
After a month or so, many simple sites work, and now the bottleneck is the stupid amount of JS sites use for everything, and Cloudflare which doesn't like someone using a non-officially-approved browser.
Absolutely not a replacement for Chrome or Ladybird, but it can be done already.
Showing how far one can go with modern AI tooling does matter only a little when all you do is looking at Chromium/Firefox code and recompiling the logic of it in another language.
I'll stick with Firefox.
Where was the market share for browsers in the 1980s?
Okay, sure. What was the market share for Chrome in 1999?
There are legitimate arguments against Ladybird. But pointing to the market share of a non-existent product, in a category on the verge of a paradigm shift from AI, is not one of them.
Is that what Ladybird does? Can you point to a real world example? From the blog post, it seems there are real world differences (look at the performance when resizing with heavy JS!).
You're also mixing arguments. The original arguments against ladybird (which I vividly remember as I loved following them back then) were that it would be impossible to arrive at something that works for all use cases. Ladybird would be able to render toy websites like hacker news, but nothing of worth.
It seems they were proven evidently wrong.
It was about time. BTW, when this gem uses EGui instead of QT6 (nothing against QT, but once everything uses Rust, it will be no reason to keep it) it will shine.
This is amazing!! I'm really surprised no other browser is able to do this. Is there an implicit "security" issue with it, or maybe standardization when it comes to keeping some values from DOM-Javascript in sync? Or simply an oversight in their part? In any case, congratulations to Ladybird's team. Computers are so much more capable of raw performance and computing, and it's nice that some developers out there do care heavily about it