9 ms·

I don't want rust in the kernel. As a small time developer making a hardware product, the investment to understand the kernel and how to build drivers is alread

by b20000 5y ago

I don't want rust in the kernel. As a small time developer making a hardware product, the investment to understand the kernel and how to build drivers is already huge. I have no interest in learning rust, and it will make it harder for people with limited resources to use linux in their projects.

Shared404 5y ago
To be honest, I don't think Linux being the "One True Kernel" is really worthwhile, and the benefits of adding Rust to the kernel outweigh the downsides. There are plenty of other kernels available for embedded work, and my understanding of Rust in the Linux kernel is that it's mostly drivers, which seems like it would be optional for your use case. That said, I've not done much embedded, I may be misunderstanding something.
- SavantIdiot 5y ago
  Rust is a language that forces you to do things in a way that makes code more robust at the cost of a little upfront thought and inconvenience. The parent comment is complaining that Rust will make kernel dev too hard? Are they joking? It is already complicated. I would rather see a more formally constructed language used for the kernel than risk adding more C-related bugs.
  - shadowgovt 5y ago
    > It is already complicated And specifically, one of the ways in which it is complicated is that it's mostly done in a language that doesn't natively enforce memory-safe constructs, forcing developers to walk a best-practices and tooling tightrope to avoid writing code that breaks.
    - SavantIdiot 5y ago
      Why the heck is this comment grey?! At least reply and explain where they are wrong?
    - b20000 5y ago
      you know what they say - something about nature creating a better fool
      - SavantIdiot 5y ago
        You mean like not incorporating formal verification theories? Yeah: fools, all of 'em.
        b20000 5y ago
        the kernel and linux is about many important issues, not about chasing the latest language fad
        pdimitar 5y ago
        That's your misconception: you believe Rust is a fad. And there's also nothing "latest" about it; it's 10 years old.
  - gameswithgo 5y ago
    The OP might be ok with a Kernel that was just in Rust, but having a kernel witha mix of Rust and C adds complexity, both in having to master two languages to understand it well, and a more complex build system.
    - b20000 5y ago
      exactly
      - pdimitar 5y ago
        What's so bad in having to know two languages for developing drivers? Especially when knowing the second one will rid you of all memory safety bugs just because your code compiles. And to call Rust's build system is laughable. Issuing `cargo build` could not be simpler (and it includes automatic downloading of dependencies, too).
  - cogman10 5y ago
    There is also so much to rust that makes it nearly ideal for the prospect of writing a driver. For example, how many bytes are in an `int`? What is the endianess of your 32bit `int`? Rust puts up front a lot of the information crucial for cross platform development of hardware drivers. Rust has few undefined edges which is exactly where C gets into trouble. C, by design, has a bunch of undefined edges. Honestly, the biggest downside to Rust in the kernel is that Rust is backed by the LLVM, which doesn't have as many supported targets as GCC does. (And, AFAIK, GCC is generally the preferred compiler for the kernel).
    - littlestymaar 5y ago
      > Honestly, the biggest downside to Rust in the kernel is that Rust is backed by the LLVM, which doesn't have as many supported targets as GCC does. (And, AFAIK, GCC is generally the preferred compiler for the kernel). Fortunately, there are now two competing approach to make GCC a viable compiler to Rust[1], and it's moving really fast. I think the LLVM-only situation won't get in the way more than a few more years. [1]: https://lwn.net/SubscriberLink/871283/c437c1364397e70e/ https://lwn.net/SubscriberLink/871283/c437c1364397e70e/
    - tialaramex 5y ago
      > For example, how many bytes are in an `int`? Rust and Linux both have the same name for say the 32-bit unsigned integer type, they both call that u32. This is of course a coincidence, and not an unlikely one, but it probably doesn't hurt for Linux people getting familiar with Rust.
  - b20000 5y ago
    it is already complicated. so i don’t want to learn another language. i want to become BETTER at using what is there, not have a language forced onto me. i want to make my tool set smaller, not learn more tools. also, being able to use linux in an embedded system as a resource constrained developer is hugely important today. adding more tools means more dev cost.
    - pdimitar 5y ago
      Sounds like it's time to exit programming, buddy, because the world has some very bad news for you. Yeah, you'll have to keep learning tools. It's included in the big paycheck.
    - SavantIdiot 5y ago
      > i want to make my tool set smaller, not learn more tools. Ouch. Good luck with that.
quotemstr 5y ago
If everyone had your attitude, humanity would have never left the trees. There are all sorts of legitimate reasons to take it slow on adding Rust to the kernel and adopting Rust generally. The language is far from perfect. But "I don't want to learn something new"? No, that's not a legitimate reason. But Christ almighty, you don't get to block progress of all humanity (and Linux is a humanity scale project now) because you're too lazy to learn some new syntax. Memory safety is important. Memory safety bugs cause billions of dollars of damage every single year. The project if solving them is too important to get tangled up in the weeds of people who don't have "resources" to RTFM.
- rat87 5y ago
  > Many were increasingly of the opinion that they'd all made a big mistake in coming down from the trees in the first place. And some said that even the trees had been a bad move, and that no one should ever have left the oceans
- jimmaswell 5y ago
  If Rust would have just used a C-style syntax instead of this wacky quirky stuff that's needlessly hard to read, it would probably be much more widely adopted. I gave it a shot myself but I was too turned off by the friction of getting used to the syntax.
  - rtoway 5y ago
    Wacky, quirky stuff?
    - jimmaswell 5y ago
      fn sum_odd_numbers(up_to: u32) -> u32 { why fn? why switch the order around? fn and u32 and all that as if keystrokes are such a scarce resource, yet u32 f(u32 a) saves so much more than fn f(a: u32) -> u32. Closures use pipes instead of any of the existing syntaxes we're used to. Why couldn't they just use the familiar concept of classes instead of whatever is going on with their strange NIH traits? NIH describes the whole language, every little thing has to be different somehow. C with Rust's safety guarantees, OOP style classes, and a few more bells and whistles could have taken over the world a lot faster, but instead we have something with a high friction to learning that will be adopted much more slowly by either programmers with a fresh start to whom every language is equally weird, or the relative minority of experienced programmers with the will and free time to push past the friction.
pizza234 5y ago
> I don't want rust in the kernel. As a small time developer making a hardware product, the investment to understand the kernel and how to build drivers is already huge. There's a crucial part missing: the investment [...] to build (memory) unsafe drivers. I find it very troubling when memory unsafe language programmers don't weigh memory safety at all in their views. (note that this doesn't necessarily refer to Rust; there's people who swear that one can build drivers also in Golang, so assuming that is realistic, the same reasoning applies)
- NextHendrix 5y ago
  Wouldn't it make more sense to use a much more mature safety-centric language with a proper language spec like Ada?
  - oxnrtr 5y ago
    No.
  - mustache_kimono 5y ago
    Ada maybe isn't very well adapted to kernel code? From what I know of Ada, doesn't it get it's memory safety from either a GC or not freeing memory entirely? That is -- ownership rules are pretty new to Ada/SPARK. C-style syntax and community interest also favor Rust. This spec argument has always seemed like a red-herring to me. Can you explain why the Ada spec would be a significant factor in this instance?
    - modshatereality 5y ago
      It's always fun to read peoples drive-by opinions about the only decent language IMO. Ada is highly compatible with C code. For dynamic allocations with "ownership" there is the concept of memory pools which CAN use a GC if thats how you choose to implement the pool allocator.
      - mustache_kimono 5y ago
cannabis_sam 5y ago
I personally hope that linux kernel development won’t be constricted by the needs of hardware devs…
- phendrenad2 5y ago
  The problem is, it isn't "needs of hardware devs" vs "rust". The kernel exists to abstract over hardware. Almost everything in the kernel* is written by "hardware devs". So any benefit Rust brings will be FOR the benefit of hardware devs. * - There is some cryptography stuff in the kernel (that probably doesn't need to be in there anyway) and that isn't written by hardware devs I suppose.
- shadowgovt 5y ago
  Isn't a big chunk of a kernel's job providing a standard abstraction for hardware access? I'd assume naively that such a construct would, of necessity, involve the needs of hardware devs.
  - cannabis_sam 5y ago
    Absolutely! I was emphatically not suggesting that the needs of hardware devs should be ignored, just that those needs should not constrict kernel development to the detriment of other concerns.
    - cannabis_sam 5y ago
      (empathetically*)
solmag 5y ago
Rust in itself is easier to understand and reason about than the equivalent kernel C code in my experience. The actual cognitive cost does not come from Rust itself, but from mixing the two memory models and interop between them, IME and is probably a bad idea in general. Should just boil the ocean and write the entire LK with Rust only.

by b20000 5y ago

Shared404 5y ago

To be honest, I don't think Linux being the "One True Kernel" is really worthwhile, and the benefits of adding Rust to the kernel outweigh the downsides. There are plenty of other kernels available for embedded work, and my understanding of Rust in the Linux kernel is that it's mostly drivers, which seems like it would be optional for your use case. That said, I've not done much embedded, I may be misunderstanding something.

SavantIdiot 5y ago
Rust is a language that forces you to do things in a way that makes code more robust at the cost of a little upfront thought and inconvenience. The parent comment is complaining that Rust will make kernel dev too hard? Are they joking? It is already complicated. I would rather see a more formally constructed language used for the kernel than risk adding more C-related bugs.
- shadowgovt 5y ago
  > It is already complicated And specifically, one of the ways in which it is complicated is that it's mostly done in a language that doesn't natively enforce memory-safe constructs, forcing developers to walk a best-practices and tooling tightrope to avoid writing code that breaks.
  - SavantIdiot 5y ago
    Why the heck is this comment grey?! At least reply and explain where they are wrong?
  - b20000 5y ago
    you know what they say - something about nature creating a better fool
    - SavantIdiot 5y ago
      You mean like not incorporating formal verification theories? Yeah: fools, all of 'em.
      - b20000 5y ago
        the kernel and linux is about many important issues, not about chasing the latest language fad
        pdimitar 5y ago
        That's your misconception: you believe Rust is a fad. And there's also nothing "latest" about it; it's 10 years old.
- gameswithgo 5y ago
  The OP might be ok with a Kernel that was just in Rust, but having a kernel witha mix of Rust and C adds complexity, both in having to master two languages to understand it well, and a more complex build system.
  - b20000 5y ago
    exactly
    - pdimitar 5y ago
      What's so bad in having to know two languages for developing drivers? Especially when knowing the second one will rid you of all memory safety bugs just because your code compiles. And to call Rust's build system is laughable. Issuing `cargo build` could not be simpler (and it includes automatic downloading of dependencies, too).
- cogman10 5y ago
  There is also so much to rust that makes it nearly ideal for the prospect of writing a driver. For example, how many bytes are in an `int`? What is the endianess of your 32bit `int`? Rust puts up front a lot of the information crucial for cross platform development of hardware drivers. Rust has few undefined edges which is exactly where C gets into trouble. C, by design, has a bunch of undefined edges. Honestly, the biggest downside to Rust in the kernel is that Rust is backed by the LLVM, which doesn't have as many supported targets as GCC does. (And, AFAIK, GCC is generally the preferred compiler for the kernel).
  - littlestymaar 5y ago
    > Honestly, the biggest downside to Rust in the kernel is that Rust is backed by the LLVM, which doesn't have as many supported targets as GCC does. (And, AFAIK, GCC is generally the preferred compiler for the kernel). Fortunately, there are now two competing approach to make GCC a viable compiler to Rust[1], and it's moving really fast. I think the LLVM-only situation won't get in the way more than a few more years. [1]: https://lwn.net/SubscriberLink/871283/c437c1364397e70e/ https://lwn.net/SubscriberLink/871283/c437c1364397e70e/
  - tialaramex 5y ago
    > For example, how many bytes are in an `int`? Rust and Linux both have the same name for say the 32-bit unsigned integer type, they both call that u32. This is of course a coincidence, and not an unlikely one, but it probably doesn't hurt for Linux people getting familiar with Rust.
- b20000 5y ago
  it is already complicated. so i don’t want to learn another language. i want to become BETTER at using what is there, not have a language forced onto me. i want to make my tool set smaller, not learn more tools. also, being able to use linux in an embedded system as a resource constrained developer is hugely important today. adding more tools means more dev cost.
  - pdimitar 5y ago
    Sounds like it's time to exit programming, buddy, because the world has some very bad news for you. Yeah, you'll have to keep learning tools. It's included in the big paycheck.
  - SavantIdiot 5y ago
    > i want to make my tool set smaller, not learn more tools. Ouch. Good luck with that.

quotemstr 5y ago

If everyone had your attitude, humanity would have never left the trees. There are all sorts of legitimate reasons to take it slow on adding Rust to the kernel and adopting Rust generally. The language is far from perfect. But "I don't want to learn something new"? No, that's not a legitimate reason. But Christ almighty, you don't get to block progress of all humanity (and Linux is a humanity scale project now) because you're too lazy to learn some new syntax. Memory safety is important. Memory safety bugs cause billions of dollars of damage every single year. The project if solving them is too important to get tangled up in the weeds of people who don't have "resources" to RTFM.

rat87 5y ago
> Many were increasingly of the opinion that they'd all made a big mistake in coming down from the trees in the first place. And some said that even the trees had been a bad move, and that no one should ever have left the oceans
jimmaswell 5y ago
If Rust would have just used a C-style syntax instead of this wacky quirky stuff that's needlessly hard to read, it would probably be much more widely adopted. I gave it a shot myself but I was too turned off by the friction of getting used to the syntax.
- rtoway 5y ago
  Wacky, quirky stuff?
  - jimmaswell 5y ago
    fn sum_odd_numbers(up_to: u32) -> u32 { why fn? why switch the order around? fn and u32 and all that as if keystrokes are such a scarce resource, yet u32 f(u32 a) saves so much more than fn f(a: u32) -> u32. Closures use pipes instead of any of the existing syntaxes we're used to. Why couldn't they just use the familiar concept of classes instead of whatever is going on with their strange NIH traits? NIH describes the whole language, every little thing has to be different somehow. C with Rust's safety guarantees, OOP style classes, and a few more bells and whistles could have taken over the world a lot faster, but instead we have something with a high friction to learning that will be adopted much more slowly by either programmers with a fresh start to whom every language is equally weird, or the relative minority of experienced programmers with the will and free time to push past the friction.

pizza234 5y ago

> I don't want rust in the kernel. As a small time developer making a hardware product, the investment to understand the kernel and how to build drivers is already huge. There's a crucial part missing: the investment [...] to build (memory) unsafe drivers. I find it very troubling when memory unsafe language programmers don't weigh memory safety at all in their views. (note that this doesn't necessarily refer to Rust; there's people who swear that one can build drivers also in Golang, so assuming that is realistic, the same reasoning applies)

NextHendrix 5y ago
Wouldn't it make more sense to use a much more mature safety-centric language with a proper language spec like Ada?
- oxnrtr 5y ago
  No.
- mustache_kimono 5y ago
  Ada maybe isn't very well adapted to kernel code? From what I know of Ada, doesn't it get it's memory safety from either a GC or not freeing memory entirely? That is -- ownership rules are pretty new to Ada/SPARK. C-style syntax and community interest also favor Rust. This spec argument has always seemed like a red-herring to me. Can you explain why the Ada spec would be a significant factor in this instance?
  - modshatereality 5y ago
    It's always fun to read peoples drive-by opinions about the only decent language IMO. Ada is highly compatible with C code. For dynamic allocations with "ownership" there is the concept of memory pools which CAN use a GC if thats how you choose to implement the pool allocator.
    - mustache_kimono 5y ago

cannabis_sam 5y ago

I personally hope that linux kernel development won’t be constricted by the needs of hardware devs…

phendrenad2 5y ago
The problem is, it isn't "needs of hardware devs" vs "rust". The kernel exists to abstract over hardware. Almost everything in the kernel* is written by "hardware devs". So any benefit Rust brings will be FOR the benefit of hardware devs. * - There is some cryptography stuff in the kernel (that probably doesn't need to be in there anyway) and that isn't written by hardware devs I suppose.
shadowgovt 5y ago
Isn't a big chunk of a kernel's job providing a standard abstraction for hardware access? I'd assume naively that such a construct would, of necessity, involve the needs of hardware devs.
- cannabis_sam 5y ago
  Absolutely! I was emphatically not suggesting that the needs of hardware devs should be ignored, just that those needs should not constrict kernel development to the detriment of other concerns.
  - cannabis_sam 5y ago
    (empathetically*)

solmag 5y ago

Rust in itself is easier to understand and reason about than the equivalent kernel C code in my experience. The actual cognitive cost does not come from Rust itself, but from mixing the two memory models and interop between them, IME and is probably a bad idea in general. Should just boil the ocean and write the entire LK with Rust only.