Today Rust does not overlap Linux in terms of platform support. There are (small but very much alive) communities doing Linux on architectures that Rust has no support for and in some cases has no plans ever to support. So this makes drivers the only case where choosing Rust doesn't mean some people lose out, as a platform e.g. with no PCI bus doesn't get to run PCI drivers even if they were written in C.
I expect that over the next say, five to ten years, two things will happen to greatly improve this, maybe to the point where you absolutely could rewrite core Linux code in Rust if you wanted to. Firstly, Rust will get more platform support. Linux doesn't really need Rust's "Tier 1" (Linus doesn't check every kernel release passes tests on all real Linux target hardware as I understand it) but clearly you want Rust to at least build and take patches for every Linux platform some day. Secondly, some older platforms will "rust out". If your community is nursing 30+ year old hardware and increasingly more maintenance work is shared between fewer shoulders at some point "Linux-next" is not a priority and your platform will stop being supported while effort moves to exciting new hardware.
Nit, I believe actually the Rust and Linux platform sets would be considered "overlapping sets" in the mathematical sense :), since neither is a subset of the other.
e.g. Rust platforms include things like the NetBSD Rump Kernel and Redox and I think one would be hard-pressed to claim that Linux supports those as platforms.
I'm interested in kernel development and I like the idea of working on it for a living. Can you give more details about your job? What does it consist in? Is it mostly code-review? Or are you responsible for maintaining a part of the kernel. Who is the entity that pays you, and what are the criteria they'd use to pay a new contributor to work on kernel full-time? Finally, can you point me to beginner-friendly things to work on to get started? how do I know which part of the kernel I should study and contribute to?
Hence the crazy idea of now using WebAssembly in Firefox modules instead.
Not to mention how much less experience you need in Rust to not blow everybody's feet off by mistake. I reckon if you have 10 years C++ and six months Rust, any Rust you write is already more likely to deliver reasonable performance without setting everything on fire than your C++. Because of the constant exposure to outright malevolent stinking garbage (in the form of other people's HTML, CSS and Javascript) the browser needs to be exceptionally robust, and C++ just isn't very good for that. So Rust is often a better fit for what Mozilla do.
Chrome folks have been playing with Rust, but seem more keen in improving their C++ static analysis tooling instead.
As for Mozilla, it is 10% of Rust code and lets see for how long Firefox still matters, given the existing 3% market, even EdgeChrome has surpassed it.
I would say that at this point that's good money after bad. Linus of course also put a bunch of effort into static analysis, that's what "sparse" is.
The thing you run into immediately is that your programming language doesn't express the thing you wanted to analyse very well. So you have to annotate your software (Linux is sprinkled with sparse annotations), and now you've added an extra opportunity for mistakes, because the annotations are transparent to the compiler, so you can write code which analyses as correct but compiles to something incorrect. "Hooray".
Most of that code is surely related to what was replaced initially instead of new subsystems being ported.
Irrelevant to the question of how much Rust is in Firefox.
> is surely
Okay, it's clear you're not going to change your mind, no matter what.
What Mozilla did do was lay off many of the people working on Rust itself as their full-time job, as opposed to people who use Rust to do their work at Mozilla. And the Servo team, unfortunately.
The 10% as pointed out in a sibling comment, while admirable isn't large parts.
As you can see from the breakdown someone posted [0], almost two-thirds of the Firefox codebase is HTML / JavaScript / Python (for tests) / assembly / Java (for Android), none of which is a candidate for being rewritten in Rust to begin with.
If you just look at the portion written in native system languages, Rust is slightly more than 1/3 of that code already and still climbing.
you think that might do it?
I'm tired of having to deal with this culture war crap in our profession. These languages are tools. C, C++, and Rust all compile down to the same LLVM IR (or GCC if you stray from rustc). There are certainly semantic and grammatical peculiarities that affect how each of them do so[0], but by and large running a simple Rust program and a simple C program through Godbolt will do a lot to disabuse you of the idea that the two are irreconcilably different.
To anyone else who wants to write performant Rust, my advice: (1) no_std, if only to focus the mind, (2) .try_foo(), not .foo(), b/c allocation is fallible, (3) always set `opt-level` to at least 1 (1 is far further from 0 than 3 is from 1, ime), (4) use stack-allocated alternatives to heap-allocated types ('smallvec' or equiv vs Vec, 'smolstr' vs String, &c) even at the expense of overallocating buffer space, (5) exploit vectorisation where possible (e.g. SIMD), in general practising mechanical sympathy, and (5) parallelism is not a panacea, whereas cache locality usually is. Measure everything, but also: memorise every instruction and how many cycles it takes, and think in those terms - in terms of your assembled, perhaps-handmodified code - rather than unscientific laptop benchmarks. (Jeff Dean's famous 'numbers every programmer should know' are a good start but are just the very basics, and obv his exact values are long obsolete, in some areas [disk] more than others [CPU].)
[0] These are discussed extremely soberly and intelligently here, for you or anyone else who may be interested: https://kornel.ski/rust-c-speed