Considering how Rust started as a way for Mozilla to make the Firefox browser more robust, it's kind of fun to see this sort of closing of the loop.
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.
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 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.
Everything Mozilla touches dies an undeserving death, so I hope they continue to spiral further down into irrelevance and an eventual dissolution.
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.
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.
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.
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.
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?
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).
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!
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.
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.
https://hg.mozilla.org/mozilla-central/file/tip/ipc/chromium