It shows how good their tech is that even their "competition" wants to get it
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