Supporting the use of Rust in the Chromium project
security.googleblog.com
security.googleblog.com
Working with folk who understand that nuance is the tough part.
2. Google enjoys a browser monopoly and can dictate features as standards to support their data collection and advertising business.
3. Google thanks Mozilla from the bottom of their heart for developing Rust, so all is forgotten :-)
I'm no fan of Google, but their relationship with Mozilla is complicated, not strictly adversarial.
Rust would've been a great USP for FireFox. They squandered it and now the competition is running with it. Both Google and Microsoft are all-in with Rust.
Relative to the rest of the circus, I'd say Mozilla is doing an okay job.
I don't trust Brave any more than I trust Google, since ultimately they're both funded by dwindling ad revenue.
The reason is that bugs exist primarily in new code, not code that has been untouched for a long time. While you may solve some latent memory issues by rewriting in Rust, you're likely to introduce new regressions as well which may be much worse. It makes much more sense to focus on writing your new code in the safe language and gradually migrate things only when they would require a substantial rewrite anyway.
A good takeaway is that the old code should not have exposed paths that didn't yet have a consumer. I frequently fall into the trap of making my code too general to support future use cases, and this usually ends up being rewritten when those use cases are actually implemented, or the code is just dead for the lifetime of the project.
Rust has a hard rule here, if your code wasn't marked unsafe, but it can be (ab)used in a way which causes unsafety, then the code is wrong. If the code is marked unsafe, but the safety documentation misses a key requirement and as a result you can obey the documented safety rules and still get unsafe behaviour, that code or its documentation is still wrong.
Thus in Rust it's never OK to say "You were using it wrong" on APIs unless they explicitly say they're unsafe and provide documentation on how to use them safely knowing that. Rust's sort() and sort_unstable() are trickier than the equivalents in the C++ standard library because a silly or erroneous Ord implementation like claiming to be Greater even than yourself is (stupid but) safe in Rust and must not induce unsafety in the sort() methods. In C++ 20 if your ordering constraints are bogus, you've got Undefined Behaviour immediately.
Rust can't "correctly" sort six Ponies that all insist they're the Best Pony, but it can promise that attempting to sort them is safe.
Obviously legacy code in a language with no hard rule about what's required may be more fraught, most C++ ought to be labelled "unsafe" but chances are it does not adequately document all the constraints on parameters etc. for safe use.
(Put another way: I entirely believe that rewriting old components in Rust might introduce more bugs, but might still be a net win in terms of decreasing vulnerability researcher value: 100 silly panicking overflow bugs are preferable to one "oops, underflowed the pointer and now the attacker has arb R/W at an address of their choice" bug.)
Also, they likely hire already top level C/C++ talent and they would require this talent to start adapting on something they are less proficient with.
Longer than? C++?
You might be interested in this post that shows they’re about the same - https://quick-lint-js.com/blog/cpp-vs-rust-build-times/
> Scaling beyond 17k SLOC [...] > C++ full builds scale better than Rust
Chromium has millions of line of code not 17k, so, although the scaling test is fairly artificial, rust might get worse and worse as the project get bigger. Paradoxically, the stupid include model of C++ allows to extract more parallelism form the build.
I wouldn't be surprised if C++ with modules has similar scalability behavior as rust though.
Think of WireGuard vs. OpenVPN. Sometimes when a lot of cruft and old habits have built up, there are significant advantages to starting fresh, with better ideas from the get go.
If a handful of developers at SerenityOS can write a web browser (including Javascript and CSS support) from scratch in a year or so why can't Mozilla rewrite the FireFox engine in Rust?
Every project should have exactly zero (0) memory bugs. That's nigh impossible to achieve with large codebases written in C/C++ or some other unsafe language.
Chromium and FireFox are still busily fixing memory bugs twenty years after the code was written. It's a God-awful mess!
Most definitely! But how many bugs were in the code that are no longer there? And how does the relative severity compare between new bugs and old bugs?
When considering a rewrite, the question isn't whether there are latent bugs, the question is whether fixing those bugs is worth the regressions that will likely be introduced (not to mention the cost).
They're scrambling to find revenue, and funding a blue-sky effort like Rust, as great as it is for the industry, just isn't something they can afford.
Also their crusade against taking money from Google is ill-conceived. There's simply no other source of revenue for a web browser (unless they start their own search engine, but that would be suicide since Google would immediately cut off their funding).
They should focus on building the best and most secure browser and then their market share will almost certainly improve.
Management are filthy crooks, scum and carpetbaggers.
False. You haven’t been paying attention.
https://hg.mozilla.org/mozilla-central/file/tip/ipc/chromium
How does being the guardian behind the language help Mozilla in any way?
Google has all the resources and hundreds of engineers to throw at Rust. They will definitely have undue influence on the language and its community now that it's in Chrome. I just hope it doesn't wind up looking like Kotlin.
Mozilla is struggling. Firefox's market share is less than 3%, in the "also ran" category. Employing all the people in the Silicon Valley to maintain Rust is hugely expensive without an obvious return on financial investment.
By opening Rust up to the community, they ensured its popularity and longevity beyond what more corporate-focused languages (Go, Swift, or C#) can achieve. Relinquishing control is exactly what Rust needed to help its popularity.
Certainly not having a bunch of engineers employed specifically to develop and maintain Rust hurts, but Mozilla simply cannot afford it.
Successful programming languages tend to be bad for business: they generate support costs but little or no measurable income.
The only way to make them profitable is to use them as a lock-in tool for your platform (VB, .Net, SQL dialects...), but Mozilla never had anything to lock people in.
Maybe? But that's not why they did it. In the same year that their CEO took another massive payout they laid off tons of staff "because covid", an excuse that was obviously nonsense at the time but especially looks like nonsense when you realize that tech absolutely exploded during covid with record high valuations.
Mozilla absolutely could have afforded it. Easily.
Mozilla's CEO is an absolutely disaster and the company is never going to be able to recover from it.
Everything Mozilla touches dies an undeserving death, so I hope they continue to spiral further down into irrelevance and an eventual dissolution.
Mozilla has also never really controlled Rust's development, it was their policy to treat it independently. The big tech companies also don't control it now. This might change in the future due to a weakened core team creating a vacuum that might be filled by the foundation, but the current status is that Rust is quite independent.
Somewhere, the laid-off Mozilla Servo team just took a swig from their hip flask.
https://github.com/Ms2ger - at Igalia in Spain https://en.wikipedia.org/wiki/Igalia
https://github.com/emilio - still at Mozilla?
https://github.com/jdm - works at CashApp https://en.wikipedia.org/wiki/Cash_App
Cheers to Graydon and Mozilla. Let an elevator never fail you again.
More browser code being written in a language with fewer footguns is always cause for celebration
I work on a large c++ project, and our compile times are awful. From my limited experience, moving to rust would absolutely ruin our compile times.
[0]: https://bevyengine.org/learn/book/getting-started/setup/#ena...
Rust, even more so than C++ code bases I've worked on and with, really tries to do lots of static typing and mono morphizing. If you work with large projects using boost and eigen, or other template libraries like them compile times are far from amazing. Compared to something like Qt where mostly its dynamic typing at work, and compile times were usually pretty reasonable.
There are also patterns that can really bloat compile time, especially heavy use of procedural macros to autogenerate code. Using serde to serialize big, complex data types can be a big compile time hit. Monomorphization can also be a problem, but fortunately careful use of boxing of dyn traits can help a lot with both code size and compile time (miniserde is an alternative to serde that's more optimized on these dimensions).
There's also continual and ongoing work to improve compile times. So overall I would say it's definitely a factor, but not necessarily a showstopper.
The same can be said about c++.
On the other points, every rust project I've seen in the wild makes heavy heavy use of macros, and the majority of projects I've used have a dependency like serde or something. If you're willing to avoid procedural macros and large dependencies, you might as well just work in c++, avoid custom templates and enjoy wicked fast iteration times.
> So overall I would say it's definitely a factor, but not necessarily a showstopper.
I disagree, it is a showstopper for now. It might not be in the future but the situation right now is that comparable c++ and rust projects in my experience have been an order of magnitude in the difference in compile times. My work c++ codebase is a 30 minutes clean build on a 32 core machine with 96GB ram and an NVMe SSD. I can only imagine what an equivalent project would be in my rust if it were as large.
Admittedly Tint is more mature and sophisticated, but both serve the function I need them for.
By your logic, Python is king over Go since Python doesn’t need to compile at all.
It was amusing to me that often times the answer in Go to avoiding repeating yourself was creating a code generator though, because the language didn't have the native abilities in macros/generics/meta programming itself to do it.
I do think the quick iteration tapers off though the larger the code base gets due to the points I mentioned.
That is after all what this link is telling us. One of the main points made was "speed up development"
If it were solely about compile times that wouldn't be a major reason to use Rust here.
I think many people do not understand that race conditions are a direct consequence of the complexity of our CPUs, memory etc. It is not the "flawed" programming language design that allowed them to sneak in but it is because the problem isn't fundamentally solvable.
Some languages try to minimize the surface area but it's not for free: there's always a trade-off attached to it. In that sense it is not anymore a bare-metal language.
In C++ if you write a data race, that's Undefined Behaviour, game over. This difference might be astonishing, but it's a fundamental design choice.
The data race requires two things to coincide and in (safe) Rust they can't. You need mutation of a value which isn't synchronised with access to that value. In concurrent C or C++ it's trivial to do this by mistake, you now have a data race and so UB. But you can't write this in safe Rust.
I write multithreaded code every day, and I'm constantly pushing for us modernizing and cleaning up our c++ codebase. Mistakes happen, subtle bugs slip through, but probably 95% of the code I write and features I write don't benefit from the extra checks that rust provides. The 5% that _do_, that's a trade-off, and we need to decide whether it's worth it. In the long tail, yeah there's less bugs of various categories.
Is that worth the cost of the rewrite and the productivity hit for 95% of what I do (as someone who would genuinely benefit from having a borrow checked), the answer right now is probably not
Obliviously if you can use Rust, it's even better but that's not always the case.
My experience in both (10+ years for C and C++ at this point, 3+ for Rust) is the exact opposite; I can't remember the last time a C or C++ build system, test framework, documentation engine made me one tenth as happy and satisfied as `cargo` does.
To be more than a FUD, you should specify which Linux distribution and which architecture. Yes, it was bad in Rust's early days, but not anymore. I speak this as someone who worked to improve Rust support in Linux distributions and across architectures.
It is fair to say Swift support in Linux distributions is spotty, as Swift is not packaged in Debian at all, and Swift upstream is developed against its own LLVM fork, which distributions are reluctant to package. I don't think it is fair to say the same to Rust. Rust upstream takes care to support LLVM releases, precisely so that it is easier to package by Linux distributions.
Ah yes, Linux is the only OS in the world. How could I forget that?
And then even Rust is not a guarantee that an application has no vulnerabilities, as memory isn’t everything.
So please use rust if it make sense, but please also don’t force it upon every possible c++ software projects.
Anyway it will be much slower to write bad code in it, with the compiler kvetching the whole time, so the rate of accumulation of bad code will necessarily be lower.
I don't agree that the decisions at the time were reasonable. Coding in Google-dialect C++ was a spectacularly bad choice, evident even then. Each day they stick to it is another equally bad choice, well into thousands now.
It's an absolutely massive codebase.
Hundreds of people are writing it even now, adding to that massive codebase. The people writing code in Rust will mostly be drawn from among those same people.
They might not be the ones who have been coding the bugs. If not, the new code will, perforce, not be less buggy. If they are the ones who have been coding the bugs, we should expect new bugs.
Chrome was released 14 years ago, and they started writing it even earlier than that, so even trivial "passage of time" would tell you it was unlikely to be true - most developers are not working on the same codebase or even at the same company, they did 14 years ago. This was much more common in tech decades ago , but not anymore, and not been true for a long time.
So even if it was "bad old code" (which, i'll explain, is also nonsense), the same people aren't writing it.
As for "bad old code" - Chrome was faster, safer, less janky, etc, than its contemporaries for many many years since inception.
So when you say "Coding in Google-dialect C++ was a spectacularly bad choice, evident even then", it just makes you look silly - it clearly was not. If it was such a bad choice, evident even then, the former would not have happened.
Overall - to look at clear success and basically say "they totally fucked everything up, and i wouldn't have done it, because i know better", is pretty arrogant. To then think that if there are bad design decisions, the main bad ones from decades ago are the programming language, is honestly the most hilariously arrogant thing i've read on HN in a while.
So congrats?
It is face-saving to blame the programming language, but we should not be fooled. Canonically, the good craftsman does not blame the tool.
> Canonically, the good craftsman does not blame the tool.
Yeah that's so true, that's why we build our sky scrapers by bashing rocks into wood and walling it up with dried feces and dirt, right?
It is probably true that Google staff, with their existing education and background, cannot achieve this, but other organizations do.
There is of course no possibility of Google recoding all of Chromium in modern C++ or Rust, so they will live with the bugs they have already coded. A new browser, such as Ladybird, could avoid Google's failings.
We do not know if next year's car will actually be notably, or even any, better than this year's. The article says they hope so, but obviously nobody knows. Probably there will be fewer of a class of bugs in the new code, but there might also be radically less code implementing needed features. We can only wait and see.
I assure you they’re not embarrassed they didn’t write it in rust from the beginning and they’re not embarrassed to have written the best and most successful browser there is.
We can anyway be certain Google does not need unpaid help defending them.
I use firefox for ideological reasons, but there is no denying that it is the (slightly) worse choice from a pure tech perspective.
If we had no Toyota or Honda to compare to, one might then insist cars could not be reliable. One might even point to Jeep and Tesla and claim Ford and Chevy were exemplary, by comparison. But we happen to know cars can be better because we have better cars.
Some people are so fragile…
Just feels weird to feel so strongly about that aspect of a programming language. If people held a principled view they’d be horrified of how militaries use anything and everything mainstream.
Time will tell, I guess…
I mean, if a handful guys at SerenityOS can write a web browser from scratch in just a few years surely Google can muster enough manpower to rewrite Chromium in Rust in a couple of years?
Interop is wasteful since there's a large discrepancy between C++ and Rust code. Trying to plug the holes will lead to an inferior product at great cost.
It does prove you can get something working. But it will take many more years to actually get to feature parity given the long tail of web APIs. It will also take many more years to be competitive on performance with existing engines. And even if you use a memory-safe language you'll be introducing many other bugs along the way.
This doesn't diminish the LadyBird browser in any way! It can still be useful for many people in many ways.
Because I agree.
LadyBird only needs video and WebRTC to be fully functional for day-to-day use by non-power users.
WebSockets and WebGL would be nice too, but that will take some time. Most other API's are cruft, such as WebUSB (a Google contraption that more or less ignores security).
Simply rewrite the core of a browser that has been in development since 1998. Easy.