1. 23
  1.  

  2. 10

    Woah. I had higher standards for conversations in a kindergarten. Laughable. Missing parenthesis are a problem? I can’t help but wonder what would they say if they stumbled upon other features of the language beyond missing parenthesis like traits, metaprogramming, typestate driven design, hygenic macros etc. They have no idea about the language and are completely disinterested. How one can even have a reasonable discussion after a joke of a statement like this. Regardless of what kind of problems Rust is causing or solving, this pathetic, annoying, dismissive, passive-agressive tone will make it very hard to progress. Even with much better driver/kernel module examples and APIs.

    1. 4

      There’s quite a bit of an impedance mismatch at the community level and it seeps through a lot in these scenarios. “Quality discourse” like this will keep happening for a while, because both communities have a lot or work to do in the “letting go of the smug dismissiveness” department. See, for example, this unofficial but pretty popular introductory document on Rust’s ownership and memory management model:

      Mumble mumble kernel embedded something something intrusive.

      It’s niche. You’re talking about a situation where you’re not even using your language’s runtime. Is that not a red flag that you’re doing something strange?

      It’s also wildly unsafe.

      But sure. Build your awesome zero-allocation lists on the stack.

      It’s a story as old as comp.lang.lisp: people who do meaningful work in a language and are otherwise completley uninvolved in language fanboy flamewars get flak because of the more visible fan discourse, which is exactly what you expect from fan discourse.

      1. 1

        Indeed. Many in the kernel community must vividly remember the history of people wanting C++ in Linux. And the swarm of Rust fanboys in 2021 must look very similar to C++ fanboys a couple of decades ago.

        Someone with an intimate knowledge of each of the languages can probably choose the right tool for the job. Meanwhile someone that only knows one language well will always prefer it – which is not unreasonable!

        My own limited experience with no_std Rust tells me it’s not nearly as easy to use as standard Rust, while my own limited experience with Linux tells me that not making mistakes in C kernel code is very difficult for mere mortals. I really hope Rust in Linux will be a great success, but only time will tell.

      2. 3

        Yeah, seriously. It sounded like petulant whining. From someone who’s programmed in one language forever, and hates the idea of change.

      3. 4

        Some of these comments are pretty straightforwardly from people who are just used to C and don’t want to deal with another language in the kernel. I’m pretty opposed to this point of view in general - programming languages are tools for programmers, and a good programmer should be prepared to use different tools at different times. Rust is in many ways a better tool than C, even if it has some transition costs from C, and it’s foolish to refuse to use it because you’re used to C.

        On the other hand, Torvalds’ point about panic-ing in out of memory conditions is very valid (and he’s not the only person to bring this up in a rust operating system context). I haven’t done a whole lot of Rust low-level programming myself, but I would expect that in a operating system context, you would simply not use the Rust standard library, and maybe kernel developers would write their own commonly-used primitives (like how you use printk instead of the C standard library printf), that eventually might become a “kernel-specific” mini-standard library itself, and that has the right memory allocation behavior for the Linux kernel.

        1. 1

          The panicking on allocation is a non-problem as its just a temporary state. As they stated at other points (and you can see when looking at the type-resolution for things like Vec in rust-analyzer) they are in the progress of introducing an API that allows fallible allocation and specific allocators. Though that will take some time as you may think of this like introducing fallible allocation to Java ArrayLists etc. AFAIK most people use specific crates for these tasks to work around this issue. Though that isn’t possible for everything and leaves a lot to desire.

          I think the really hard problem will be to integrate the kernel API/ABI (internal functions and structures) into rust, in a way that you don’t have to call unsafe for everything and end up with a rustic c. See also the posts of other people trying to implement a wayland protocol abstraction for rust when the whole “protocol” was designed around pointer arithmetic. (allocating a struct with your required state and passing a pointer to a function inside the struct so you can retrieve the struct and your state on callback via pointer arithmetic..)