3 ms·

Odds are it's not going to happen. You just need to read between the lines. There's a lot of handwaving from the Rust side and very little of actual importance.

Odds are it's not going to happen. You just need to read between the lines. There's a lot of handwaving from the Rust side and very little of actual importance. You gotta remember that most of the heavy hitters in Linux Kernel development haven't even commented yet. When the Rust side presents something mergeable, the massacre will begin.

nynx 5y ago
I don't see this at all. Could you point to an example?
- creamytaco 5y ago
  It's just my intuition built by reading LKML and following Linux kernel development for 20 years. There are a lot of folks waiting for something mergeable before a torrent of criticism (and I'd imagine outright NAKs) comes down. I think a lot of Rust people read Linus's "I don't hate it" as explicit approval. But anyone who's followed LKML knows that this is not the case.
  - vlovich123 5y ago
    That’s a surprising read given Linus’ general overall positive sentiment to the preliminary interactions. Yes there are concerns but it seems like the team involved is working on solving them & believes it is a tractable problem, not to mention strong support from the Rust standard library maintainers. There are always risks but I wager this is far more serious than past attempts like the C++ one which never had any significant commitments from the standards body to support kernel needs. That Rust is building a language that can fit wildly different use-cases (embedded, kernel, web servers, systems programming, etc) without serious sacrifices for other use-cases is truly impressive to me.
    - creamytaco 5y ago
      Even if Linus wants it, and this is a big stretch since "I don't hate it" is best characterized as neutral and not positive, there are others who have a say. Remember what happened with KDBUS? Gregkh fought long and hard to get it merged but in the end it didn't happen because too many people didn't want it.
      - smoldesu 5y ago
        I agree, Linus is likely pretty neutral on the topic. In the world of kernel development though, feeling "neutral" about something is about the highest praise it can receive. In other words, there's not much else that Torvalds could do to welcome Rust developers besides writing a kernel patch in the language himself.
  - toast0 5y ago
    Given the current target seems to be more or less Rust for loadable device drivers, even if it never gets merged, it could develop to the point where out of tree modules could be done consistently in Rust.
ordu 5y ago
> You gotta remember that most of the heavy hitters in Linux Kernel development haven't even commented yet. There is nothing to comment yet. I've read those driver, it seems unconvincing for me despite me being a rust fanboy. Linus said about panics, I agree completely with him, and with the possibility to get rid of those panics. There is unsafe code where it shouldn't be, for example driver uses unsafe to create and to initialize a semaphore. I believe this unsafety could be removed by using Pin or something like, but when it removed, then it would be the time to comment. And I mean it. Kernel code heavily uses list_head, for example, which is PITA with rust. How to deal with it? I'm not sure that the rust will be better than C, just because it would be rust used in a C style, but it doesn't work. When I met Rust for the first time, I tried it with a C style of designing programs. Many people do, and it just doesn't work. For now it is impossible to judge how rust will help, we might believe that it will help, because rust is a safety-oriented language, blah-blah-blah. But it is a belief, not something that we could touch, play with, see how it helps and how it obstructs.

nynx 5y ago

I don't see this at all. Could you point to an example?

creamytaco 5y ago
It's just my intuition built by reading LKML and following Linux kernel development for 20 years. There are a lot of folks waiting for something mergeable before a torrent of criticism (and I'd imagine outright NAKs) comes down. I think a lot of Rust people read Linus's "I don't hate it" as explicit approval. But anyone who's followed LKML knows that this is not the case.
- vlovich123 5y ago
  That’s a surprising read given Linus’ general overall positive sentiment to the preliminary interactions. Yes there are concerns but it seems like the team involved is working on solving them & believes it is a tractable problem, not to mention strong support from the Rust standard library maintainers. There are always risks but I wager this is far more serious than past attempts like the C++ one which never had any significant commitments from the standards body to support kernel needs. That Rust is building a language that can fit wildly different use-cases (embedded, kernel, web servers, systems programming, etc) without serious sacrifices for other use-cases is truly impressive to me.
  - creamytaco 5y ago
    Even if Linus wants it, and this is a big stretch since "I don't hate it" is best characterized as neutral and not positive, there are others who have a say. Remember what happened with KDBUS? Gregkh fought long and hard to get it merged but in the end it didn't happen because too many people didn't want it.
    - smoldesu 5y ago
      I agree, Linus is likely pretty neutral on the topic. In the world of kernel development though, feeling "neutral" about something is about the highest praise it can receive. In other words, there's not much else that Torvalds could do to welcome Rust developers besides writing a kernel patch in the language himself.
- toast0 5y ago
  Given the current target seems to be more or less Rust for loadable device drivers, even if it never gets merged, it could develop to the point where out of tree modules could be done consistently in Rust.

ordu 5y ago

> You gotta remember that most of the heavy hitters in Linux Kernel development haven't even commented yet. There is nothing to comment yet. I've read those driver, it seems unconvincing for me despite me being a rust fanboy. Linus said about panics, I agree completely with him, and with the possibility to get rid of those panics. There is unsafe code where it shouldn't be, for example driver uses unsafe to create and to initialize a semaphore. I believe this unsafety could be removed by using Pin or something like, but when it removed, then it would be the time to comment. And I mean it. Kernel code heavily uses list_head, for example, which is PITA with rust. How to deal with it? I'm not sure that the rust will be better than C, just because it would be rust used in a C style, but it doesn't work. When I met Rust for the first time, I tried it with a C style of designing programs. Many people do, and it just doesn't work. For now it is impossible to judge how rust will help, we might believe that it will help, because rust is a safety-oriented language, blah-blah-blah. But it is a belief, not something that we could touch, play with, see how it helps and how it obstructs.