5 ms·

Rust will quickly replace C in the kernel, I have no doubt about it.

by npigrounet 4y ago

kibwen 4y ago
Rust is great, but let's not get ahead of ourselves. :P
rob74 4y ago
Just as quickly as it replaced C/C++ in Firefox?
- zozbot234 4y ago
  Firefox is getting new "oxidized" component all the time, Rust is the recommended language for both refactoring and new development. Of course the lowest-hanging fruits are addressed first, but that's normal and advisable.
  - pjmlp 4y ago
    Not after they let go everyone related to Rust, as far as I am aware. Hence the crazy idea of now using WebAssembly in Firefox modules instead.
    - steveklabnik 4y ago
      That's not correct. Firefox continues to gain new Rust code. Compare https://web.archive.org/web/20201109025230/https://4e6.github.io/firefox-lang-stats/ https://web.archive.org/web/20201109025230/https://4e6.githu..., the first version of this page archive.org saved after the layoffs. 9.5% Rust, 2.9 million LOC. Today https://4e6.github.io/firefox-lang-stats/ https://4e6.github.io/firefox-lang-stats/ 10.1% Rust, 3.4 million LOC.
      - pjmlp 4y ago
        10% in a browser currently having 3% market share with a decreasing tendency towards 0%. Most of that code is surely related to what was replaced initially instead of new subsystems being ported.
        steveklabnik 4y ago
        > 10% in a browser currently having 3% market share with a decreasing tendency towards 0%. 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.
    - tialaramex 4y ago
      There's a big difference between "We don't employ the language's architects" (so far as I'm aware Mozilla also doesn't employ many WG21 members) and "We don't have any engineers who know this language". In 2022 you'd probably have to go out of your way to hire that many engineers and not get some people who know Rust. 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.
      - pjmlp 4y ago
        Yet Chrome and Safari, the browsers that really matter in 2022, won't be moving away from C++. 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.
        tialaramex 4y ago
        > Chrome folks have been playing with Rust, but seem more keen in improving their C++ static analysis tooling instead. 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".
      - npigrounet 4y ago
    - dralley 4y ago
      Please don't spout nonsense. They did not let go of "everyone related to Rust", large parts of Firefox are written in Rust and those parts obviously need to be maintained. New Rust code continues to be written, as others have pointed out. 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.
      - pjmlp 4y ago
        Hence why I mentioned "as far as I am aware" instead of stating is a fact. The 10% as pointed out in a sibling comment, while admirable isn't large parts.
        dralley 4y ago
        It's more than it sounds like. 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. [0] https://4e6.github.io/firefox-lang-stats/ https://4e6.github.io/firefox-lang-stats/
- devmunchies 4y ago
  I'm new to programming, whats Firefox?
lostmsu 4y ago
I have a very strong doubt about it because Rust debugging still sucks. No debugger allows you to evaluate function calls AFAIK, which is a very strong restriction.
- toast0 4y ago
  That doesn't seem like it would matter in the Linux kernel, since they don't have a kernel debugger, for better or worse.
  - saagarjha 4y ago
    Running GDB against the kernel running in QEMU?
  - nukemaster 4y ago
- School-Cotton 4y ago
  I have definitely evaluated function calls in rust-gdb.
  - lostmsu 4y ago
    I see reports of it working for trivial top-level functions with basic parameter types, but what about everything else? Like member functions, trait implementations, etc.
    - School-Cotton 4y ago
      You’re absolutely right that it often fails on more complicated stuff. I’m just pointing out that it’s not _totally_ nonexistent.
matheusmoreira 4y ago
I have no doubt we'll be seeing Rust kernel modules but quickly replacing C? I don't think that's realistic.
nightfly 4y ago
If you define quickly as "over the next 10-20 years, maybe", then yes
- yjftsjthsd-h 4y ago
  In fairness, that is... if not quick, then not slow either in kernel development time:)
Bancakes 4y ago
If by "replace" you mean "nobodies rewrite existing crap into Rust", then yes.
- LoveMortuus 4y ago
  That's a bit harsh of an approach. And I think at least Doom would disagree.
  - nomoreusernames 4y ago
    he means in the context of a kernel developer. im sure there is some nerd who would rewrite stuff to prove to themselves and shutup their inner imposter syndrome. but mostly its quite accurate.
    - mhaberl 4y ago
      > rewrite stuff to .. shutup their inner imposter syndrome you think that might do it?
      - Bancakes 4y ago
        Rust is evidently an impostor language.
        samhw 4y ago
        I agree that the parent claim ("Rust will quickly replace C in the Linux kernel") was utterly risible, but your comments just seem like the mirror image of theirs. What on earth is an 'impostor language'? Imposture of what or whom? 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 https://kornel.ski/rust-c-speed
ilovecaching 4y ago
I work on the kernel for a living, and I find this claim exceedingly dubious. We're currently talking about experimentally supporting modules written in Rust, which is an entirely different beast than replacing pieces of the kernel core. The barrier to entry for drivers is significantly lower, and driver quality can be much, much poorer than the quality of the core kernel. Many parts of the kernel have been fine tuned for decades, and many of the kernel developers that maintain Linux are also C experts (myself included) who aren't going to slow down development to migrate working code to Rust. It's great that we can experiment and see how Rust goes for driver authors, but they are still bus API consumers, not core kernel.
- tialaramex 4y ago
  As I understand it the crucial rationale for drivers is that drivers were anyway necessarily platform dependent which undoes one argument against Rust. 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.
  - sophacles 4y ago
    There's active work being done on the rust gcc backend and it's progressing nicely. That should help with some of the platform concerns you (rightly) raised.

Rust will quickly replace C in the kernel, I have no doubt about it.

kibwen 4y ago

Rust is great, but let's not get ahead of ourselves. :P

rob74 4y ago

Just as quickly as it replaced C/C++ in Firefox?

zozbot234 4y ago
Firefox is getting new "oxidized" component all the time, Rust is the recommended language for both refactoring and new development. Of course the lowest-hanging fruits are addressed first, but that's normal and advisable.
- pjmlp 4y ago
  Not after they let go everyone related to Rust, as far as I am aware. Hence the crazy idea of now using WebAssembly in Firefox modules instead.
  - steveklabnik 4y ago
    That's not correct. Firefox continues to gain new Rust code. Compare https://web.archive.org/web/20201109025230/https://4e6.github.io/firefox-lang-stats/ https://web.archive.org/web/20201109025230/https://4e6.githu..., the first version of this page archive.org saved after the layoffs. 9.5% Rust, 2.9 million LOC. Today https://4e6.github.io/firefox-lang-stats/ https://4e6.github.io/firefox-lang-stats/ 10.1% Rust, 3.4 million LOC.
    - pjmlp 4y ago
      10% in a browser currently having 3% market share with a decreasing tendency towards 0%. Most of that code is surely related to what was replaced initially instead of new subsystems being ported.
      - steveklabnik 4y ago
        > 10% in a browser currently having 3% market share with a decreasing tendency towards 0%. 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.
  - tialaramex 4y ago
    There's a big difference between "We don't employ the language's architects" (so far as I'm aware Mozilla also doesn't employ many WG21 members) and "We don't have any engineers who know this language". In 2022 you'd probably have to go out of your way to hire that many engineers and not get some people who know Rust. 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.
    - pjmlp 4y ago
      Yet Chrome and Safari, the browsers that really matter in 2022, won't be moving away from C++. 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.
      - tialaramex 4y ago
        > Chrome folks have been playing with Rust, but seem more keen in improving their C++ static analysis tooling instead. 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".
    - npigrounet 4y ago
  - dralley 4y ago
    Please don't spout nonsense. They did not let go of "everyone related to Rust", large parts of Firefox are written in Rust and those parts obviously need to be maintained. New Rust code continues to be written, as others have pointed out. 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.
    - pjmlp 4y ago
      Hence why I mentioned "as far as I am aware" instead of stating is a fact. The 10% as pointed out in a sibling comment, while admirable isn't large parts.
      - dralley 4y ago
        It's more than it sounds like. 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. [0] https://4e6.github.io/firefox-lang-stats/ https://4e6.github.io/firefox-lang-stats/
devmunchies 4y ago
I'm new to programming, whats Firefox?

lostmsu 4y ago

I have a very strong doubt about it because Rust debugging still sucks. No debugger allows you to evaluate function calls AFAIK, which is a very strong restriction.

toast0 4y ago
That doesn't seem like it would matter in the Linux kernel, since they don't have a kernel debugger, for better or worse.
- saagarjha 4y ago
  Running GDB against the kernel running in QEMU?
- nukemaster 4y ago
School-Cotton 4y ago
I have definitely evaluated function calls in rust-gdb.
- lostmsu 4y ago
  I see reports of it working for trivial top-level functions with basic parameter types, but what about everything else? Like member functions, trait implementations, etc.
  - School-Cotton 4y ago
    You’re absolutely right that it often fails on more complicated stuff. I’m just pointing out that it’s not _totally_ nonexistent.

matheusmoreira 4y ago

I have no doubt we'll be seeing Rust kernel modules but quickly replacing C? I don't think that's realistic.

nightfly 4y ago

If you define quickly as "over the next 10-20 years, maybe", then yes

yjftsjthsd-h 4y ago
In fairness, that is... if not quick, then not slow either in kernel development time:)

Bancakes 4y ago

If by "replace" you mean "nobodies rewrite existing crap into Rust", then yes.

LoveMortuus 4y ago
That's a bit harsh of an approach. And I think at least Doom would disagree.
- nomoreusernames 4y ago
  he means in the context of a kernel developer. im sure there is some nerd who would rewrite stuff to prove to themselves and shutup their inner imposter syndrome. but mostly its quite accurate.
  - mhaberl 4y ago
    > rewrite stuff to .. shutup their inner imposter syndrome you think that might do it?
    - Bancakes 4y ago
      Rust is evidently an impostor language.
      - samhw 4y ago
        I agree that the parent claim ("Rust will quickly replace C in the Linux kernel") was utterly risible, but your comments just seem like the mirror image of theirs. What on earth is an 'impostor language'? Imposture of what or whom? 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 https://kornel.ski/rust-c-speed

ilovecaching 4y ago

I work on the kernel for a living, and I find this claim exceedingly dubious. We're currently talking about experimentally supporting modules written in Rust, which is an entirely different beast than replacing pieces of the kernel core. The barrier to entry for drivers is significantly lower, and driver quality can be much, much poorer than the quality of the core kernel. Many parts of the kernel have been fine tuned for decades, and many of the kernel developers that maintain Linux are also C experts (myself included) who aren't going to slow down development to migrate working code to Rust. It's great that we can experiment and see how Rust goes for driver authors, but they are still bus API consumers, not core kernel.

tialaramex 4y ago
As I understand it the crucial rationale for drivers is that drivers were anyway necessarily platform dependent which undoes one argument against Rust. 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.
- sophacles 4y ago
  There's active work being done on the rust gcc backend and it's progressing nicely. That should help with some of the platform concerns you (rightly) raised.