8 ms·

I am split on this. Maybe I am idealistic and naive, but I will always wish people can just stop fighting, and work together. Fragmenting the community and star

by yshui 2y ago

I am split on this. Maybe I am idealistic and naive, but I will always wish people can just stop fighting, and work together. Fragmenting the community and starting a project out of grudge, is always the last resort, IMO. OTOH, I also recognize sometimes it is really that bad and going your own way is the best thing to do. But I think Linux isn't at that position yet.

snvzz 2y ago
Replacing C with Rust within the kernel is not going to be peaceful. It's been made clear by now that most Linux developers, including those most prominent, prefer C and do not wish to invest any time or effort accommodating Rust developers. >but I will always wish people can just stop fighting, and work together. Two separate ideas are conflated here. It would make me happy if they stopped fighting, and instead worked separately on their C and Rust kernels respectively.
- steveklabnik 2y ago
  > including those most prominent, The most prominent one is supportive of Rust. And traditionally when it comes to technical decisions, it is his opinion that matters most.
  - snvzz 2y ago
    >The most prominent one is supportive of Rust It is the premise. Without his acceptance of Rust, we wouldn't be at this point. But he can't realistically do the relevant rust-accommodation work all by himself. Not does he seem supportive of Rust enough as to replace the top maintainers he trusts and has worked with for a very long time with those that will extend the red carpet for Rust developers. Perhaps Linus was trying to be kind. But sometimes, just saying "No." is most kind. He didn't have the luxury of hindsight. He tried to be accommodating. Now, we are in a situation that is not pleasant for anybody involved.
    - nequo 2y ago
      The problem is that neither Linus nor the other prominent maintainers will live forever. C was the right choice in 1991 but today the landscape is different enough that its shortcomings, for the younger generations, are painful to ignore. So saying yes to Rust, or to some other language that is not filled with foot guns and could also work in the kernel space, is not only a matter of kindness but a matter of long-term strategy for the kernel.
      - snvzz 2y ago
        >The problem is that neither Linus nor the other prominent maintainers will live forever. I agree. But likewise, Linux's design is far from the state of the art. Maybe there's value in letting it be what it always has been. It is not realistic to try to migrate millions of LoCs written with poor structure, to properly structured Rust, with barely any support from the pre-existing developers. At some time, it makes sense to move on to something better. This hypothetical system be written in a different language. It could be Rust, it could be C23, or something else entirely. But what it will definitely be is better structured. It would have clean, versioned APIs. And drivers will no doubt run in user space.
        iknowstuff 2y ago
        I’ve become convinced that complex things in tech either ossify and get stuff built on top of them, or get Ship of Theseus’d. It’s extremely rare for an outright replacement to replace something overnight. Linux is not going to be suddenly replaced by something incompatible, but I’m concinved it will become more oxidized over time. If not under Linus, then under an initially fully compatible corporate fork which would ultimately become more popular. So there’s some pressure on Linus to move it along .
        snvzz 2y ago
        This is typically the case. But the argument being made is that Linux is particularly ill suited for an in-place conversion to a better design.
  - lelanthran 2y ago
    > The most prominent one is supportive of Rust. "supportive" is not a binary. Interpreting "no immediate objections" as "this is what I want" is specious and intellectually dishonest.
- MBCook 2y ago
  Prefer C? Or haven’t used Rust? All the Rust kernel developers have to know C. Is that true of the bigger maintainers who are arguing against it? It’s fine to prefer one over the other. If you haven’t learned one and refuse to try it and your argument boils down to “it’s not what we’ve done and I don’t want to change” that’s not good technical decision making.
  - lelanthran 2y ago
    > If you haven’t learned one and refuse to try it and your argument boils down to “it’s not what we’ve done and I don’t want to change” that’s not good technical decision making. It sounds reasonable - you don't waltz into a large existing project $FOO and tell the existing maintainers "Here's our rules going forward - you shall learn $BAR!" It's both rude and arrogant. I have not seen any good arguments for why there should be an exception when $BAR == Linux and $FOO == Rust.
topspin 2y ago
> starting a project out of grudge How many times has this succeeded for fundamental work? I can think of a couple, including Xorg and GCC. I don't know if those cases can be characterized as "grudges" exactly but, in each instance, someone was unsatisfied with the prevailing conditions, forked the work, and then subsumed the legacy. Doubtless there have been far more failures than successes. I also know that computing probabilities based on such ratios is simple minded: other factors exist and the equation is non-linear. > But I think Linux isn't at that position yet. I was disturbed by the irrational behavior I saw in this talk[1]. What the presenter sought was reasonable: communicate the intended semantics so Rust kernel developers can track the evolution. This was somehow understood as: forego C and become a Rust programmer, take responsibility for our work and maintain it going forward. No, I do not believe the former implies the latter. There are endless silos, both formal and informal, for both good reasons and bad reasons, permeating all intellectual work, whether "open" or not. It is entirely reasonable to imagine that this pattern can be employed among reasonable people for the matter at hand, especially for something like file systems, where even parallel implementations can and do exist simultaneously. If this behavior is prevalent enough then drastic steps are justified. Whether they're feasible or not is another matter, and also a many factored, non-linear calculation. One could, for instance, reimplement only some fraction of the kernel and be entirely sufficient for most of the backend cloud server Linux use case. Given the enthusiasm for Rust among major cloud operators, I suspect this might be attempted at some point. [1] https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1566s https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1566s
- lelanthran 2y ago
  > This was somehow understood as: forego C and become a Rust programmer, take responsibility for our work and maintain it going forward. That's how I understand it as well: the proposal is 1. Put our Rust code in. 2. If you make C-code changes that break Rust-code, then your change can't be merged until you either learn Rust or wait on us to fix things. This is an unreasonable expectation, IMO, for any large project written in any language; this is not specific to Linux and C and Rust. Making unreasonable proposals in civil language does not magically turn that proposal into a reasonable one. Pressing forward in spite of feedback that the proposal is unreasonable is uncivil, even if you spread a thin veneer of civility over it.

by yshui 2y ago

snvzz 2y ago

Replacing C with Rust within the kernel is not going to be peaceful. It's been made clear by now that most Linux developers, including those most prominent, prefer C and do not wish to invest any time or effort accommodating Rust developers. >but I will always wish people can just stop fighting, and work together. Two separate ideas are conflated here. It would make me happy if they stopped fighting, and instead worked separately on their C and Rust kernels respectively.

steveklabnik 2y ago
> including those most prominent, The most prominent one is supportive of Rust. And traditionally when it comes to technical decisions, it is his opinion that matters most.
- snvzz 2y ago
  >The most prominent one is supportive of Rust It is the premise. Without his acceptance of Rust, we wouldn't be at this point. But he can't realistically do the relevant rust-accommodation work all by himself. Not does he seem supportive of Rust enough as to replace the top maintainers he trusts and has worked with for a very long time with those that will extend the red carpet for Rust developers. Perhaps Linus was trying to be kind. But sometimes, just saying "No." is most kind. He didn't have the luxury of hindsight. He tried to be accommodating. Now, we are in a situation that is not pleasant for anybody involved.
  - nequo 2y ago
    The problem is that neither Linus nor the other prominent maintainers will live forever. C was the right choice in 1991 but today the landscape is different enough that its shortcomings, for the younger generations, are painful to ignore. So saying yes to Rust, or to some other language that is not filled with foot guns and could also work in the kernel space, is not only a matter of kindness but a matter of long-term strategy for the kernel.
    - snvzz 2y ago
      >The problem is that neither Linus nor the other prominent maintainers will live forever. I agree. But likewise, Linux's design is far from the state of the art. Maybe there's value in letting it be what it always has been. It is not realistic to try to migrate millions of LoCs written with poor structure, to properly structured Rust, with barely any support from the pre-existing developers. At some time, it makes sense to move on to something better. This hypothetical system be written in a different language. It could be Rust, it could be C23, or something else entirely. But what it will definitely be is better structured. It would have clean, versioned APIs. And drivers will no doubt run in user space.
      - iknowstuff 2y ago
        I’ve become convinced that complex things in tech either ossify and get stuff built on top of them, or get Ship of Theseus’d. It’s extremely rare for an outright replacement to replace something overnight. Linux is not going to be suddenly replaced by something incompatible, but I’m concinved it will become more oxidized over time. If not under Linus, then under an initially fully compatible corporate fork which would ultimately become more popular. So there’s some pressure on Linus to move it along .
        snvzz 2y ago
        This is typically the case. But the argument being made is that Linux is particularly ill suited for an in-place conversion to a better design.
- lelanthran 2y ago
  > The most prominent one is supportive of Rust. "supportive" is not a binary. Interpreting "no immediate objections" as "this is what I want" is specious and intellectually dishonest.
MBCook 2y ago
Prefer C? Or haven’t used Rust? All the Rust kernel developers have to know C. Is that true of the bigger maintainers who are arguing against it? It’s fine to prefer one over the other. If you haven’t learned one and refuse to try it and your argument boils down to “it’s not what we’ve done and I don’t want to change” that’s not good technical decision making.
- lelanthran 2y ago
  > If you haven’t learned one and refuse to try it and your argument boils down to “it’s not what we’ve done and I don’t want to change” that’s not good technical decision making. It sounds reasonable - you don't waltz into a large existing project $FOO and tell the existing maintainers "Here's our rules going forward - you shall learn $BAR!" It's both rude and arrogant. I have not seen any good arguments for why there should be an exception when $BAR == Linux and $FOO == Rust.

topspin 2y ago

> starting a project out of grudge How many times has this succeeded for fundamental work? I can think of a couple, including Xorg and GCC. I don't know if those cases can be characterized as "grudges" exactly but, in each instance, someone was unsatisfied with the prevailing conditions, forked the work, and then subsumed the legacy. Doubtless there have been far more failures than successes. I also know that computing probabilities based on such ratios is simple minded: other factors exist and the equation is non-linear. > But I think Linux isn't at that position yet. I was disturbed by the irrational behavior I saw in this talk[1]. What the presenter sought was reasonable: communicate the intended semantics so Rust kernel developers can track the evolution. This was somehow understood as: forego C and become a Rust programmer, take responsibility for our work and maintain it going forward. No, I do not believe the former implies the latter. There are endless silos, both formal and informal, for both good reasons and bad reasons, permeating all intellectual work, whether "open" or not. It is entirely reasonable to imagine that this pattern can be employed among reasonable people for the matter at hand, especially for something like file systems, where even parallel implementations can and do exist simultaneously. If this behavior is prevalent enough then drastic steps are justified. Whether they're feasible or not is another matter, and also a many factored, non-linear calculation. One could, for instance, reimplement only some fraction of the kernel and be entirely sufficient for most of the backend cloud server Linux use case. Given the enthusiasm for Rust among major cloud operators, I suspect this might be attempted at some point. [1] https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1566s https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1566s

lelanthran 2y ago
> This was somehow understood as: forego C and become a Rust programmer, take responsibility for our work and maintain it going forward. That's how I understand it as well: the proposal is 1. Put our Rust code in. 2. If you make C-code changes that break Rust-code, then your change can't be merged until you either learn Rust or wait on us to fix things. This is an unreasonable expectation, IMO, for any large project written in any language; this is not specific to Linux and C and Rust. Making unreasonable proposals in civil language does not magically turn that proposal into a reasonable one. Pressing forward in spite of feedback that the proposal is unreasonable is uncivil, even if you spread a thin veneer of civility over it.