4 ms·

Hmm, this plus the performance regressions makes me wonder if it's too soon to move to the rust version of Coreutils. And makes me wonder if this is gonna cause

Hmm, this plus the performance regressions makes me wonder if it's too soon to move to the rust version of Coreutils. And makes me wonder if this is gonna cause more pushback regarding the rust in the kernel movement.

mustache_kimono 1y ago
> this is gonna cause more pushback regarding the rust in the kernel movement. Only among those that don't understand that, if this is a problem, then it is Canonical problem, not a Rust problem. To give another example, Canonical includes ZFS in Ubuntu too. And, for a while, Canonical shipped a broken snapshot mechanism called zsys with Ubuntu too. Canonical ultimately ripped zsys out because it didn't work very well. zsys would choke on more than 4000 snapshots, etc. zsys was developed in Go, while other snapshot systems developed in Perl and Python did a little less and worked better. Now, is zsys a Go problem? Of course not. It wasn't ready because Canonical sometimes ships broken stuff.
- zahlman 1y ago
  > Only among those that don't understand that, if this is a problem, then it is Canonical problem, not a Rust problem. (This is hard to express in a careful way where I'm confident of not offending anyone. Please take me at my word that I'm not trying to take sides in this at all.) The dominant narrative behind this pushback, as far as I can tell, is nothing to do with the Rust language itself (aside perhaps from a few fringe people who see the adoption of Rust as some kind of signal of non-programming-related politics, and who are counter-signaling). Rather, the opposition is to re-implementing "working" software (including in the sense that nobody seems to have noticed any memory-handling faults all this time) for the sake of seemingly nebulous benefits (like compiler-checked memory safety). The Rust code will probably also be more maintainable by Rust developers than the C code currently is by C developers given the advantages of Rust's language design. (Unless it turns out that the C developers are just intrinsically better at programming and/or software engineering; I'm pretty skeptical of that.) But most long-time C users are probably not going to want to abandon their C expertise and learn Rust. And they seem to outnumber the new Rust developers by quite a bit, at least for now.
  - deleted 1y ago
    [deleted]
  - inejge 1y ago
    > The dominant narrative behind this pushback, as far as I can tell, is nothing to do with the Rust language itself (aside perhaps from a few fringe people who see the adoption of Rust as some kind of signal of non-programming-related politics, and who are counter-signaling). Difficult to say with certainty, because it's easy to dress "political" resistance in respectable preference for stability. (Scare quotes because it's an amalgam in which politics is just a part.) Besides, TFA is Phoronix, whose commentariat is not known for subtlety on this topic. Replacing coreutils is risky because of the decades of refinement/stagnation (depending on your viewpoint) which will inevitably produce snags when component utilities interact in ways unforeseen by tests -- as has happened here. But without risk there's no reward. Of course, what's the reward here is subject to debate. IMO the self-evident advantage of a rewrite is that it's prima facie evidence of interest in using the language, which is significant if there's a dearth of maintainers for the originals. (The very vocal traditionalists are usually not in a hurry to contribute.)
    - subsistence234 1y ago
      Is there really a dearth of maintainers for the originals? They already work fine, no? To me it sounds a bit like: "Addition has become stagnant, so we need to re-implement it in higher category theory. Sure, 99% of even research mathematicians don't benefit from that re-implementation. But no risk no reward! If vocal traditionalists refuse to contribute to reinventing the wheel, maybe they're working on something that hasn't been refined/stagnated decades ago, but I won't take their perspective (that addition already works fine) seriously, unless they start re-implementing addition as well."
  - mustache_kimono 1y ago
    > Rather, the opposition is to re-implementing "working" software I understand the argument, and its sounds good as far as most things go, but it misses an important fact: In OSS, you can and should find your own bliss. If you want to learn Rust, as I did, you can do it by reimplementing uutils' sort and ls, and fixing bugs in cp and mv, as I did. That was my bliss. OSS doesn't need to be useful to anyone. OSS can be a learning exercise or it can be simply for love of the game. The fact that Canonical wants to ship it, right now, simply makes them a little silly. It doesn't say a thing about me, or Rust, or Rust culture.
- pornel 1y ago
  This is more nuanced in Rust's case. Rust is trying to systemically improve safety and reliability of programs, so the degree to which it succeeds is Rust's problem. OTOH we also have people interpreting it as if Rust was supposed to miraculously prevent all bugs, and they take any bug in any Rust program as a proof by contradiction that Rust doesn't work.
  - shikon7 1y ago
    It might be a bit of bad publicity for those who want to rewrite as much as possible in Rust. While Rust is not to blame, it shows that just rewriting something in Rust doesn't magically make it better (as some Rust hype might suggest). Maybe Ubuntu was a bit too eager in adopting the Rust Coreutils, caring more about that hype than about stability.
    - b_e_n_t_o_n 1y ago
      > Rust is not to blame Isn't that an unfalsifiable statement until the coreutils get written in another language and can be compared?
      - mustache_kimono 1y ago
        > Isn't that an unfalsifiable statement Sounds pretty axiomatic: Rust is not to blame for someone else's choice to ship beta software?
  - mustache_kimono 1y ago
    > Rust is trying to systemically improve safety and reliability of programs, so the degree to which it succeeds is Rust's problem. GNU coreutils first shipped in what, the 1980s? It's so old that it would be very hard to find the first commit. Whereas uutils is still beta software which didn't ask to be representative of "Rust", at all. Moreover, GNU coreutils are still sometimes not compatible with their UNIX forebears. Even considering this first, more modest standard, it is ridiculous to hold this software to it, in particular.
- b_e_n_t_o_n 1y ago
  It's not about rust specifically, it's about replacing working software with rewrites and going from a code base written in a single language to one written in multiple.
AllegedAlec 1y ago
People have forgotten the sacred motto "Don't Break Userspace"
- steveklabnik 1y ago
  That slogan is about the kernel, not about user space programs.
SahAssar 1y ago
> And makes me wonder if this is gonna cause more pushback regarding the rust in the kernel movement. Does this have anything at all to do with the kernel?
- shikon7 1y ago
  No, and I expect kernel developers to be much more careful not to break anything with Rust rewrites.

mustache_kimono 1y ago

> this is gonna cause more pushback regarding the rust in the kernel movement. Only among those that don't understand that, if this is a problem, then it is Canonical problem, not a Rust problem. To give another example, Canonical includes ZFS in Ubuntu too. And, for a while, Canonical shipped a broken snapshot mechanism called zsys with Ubuntu too. Canonical ultimately ripped zsys out because it didn't work very well. zsys would choke on more than 4000 snapshots, etc. zsys was developed in Go, while other snapshot systems developed in Perl and Python did a little less and worked better. Now, is zsys a Go problem? Of course not. It wasn't ready because Canonical sometimes ships broken stuff.

zahlman 1y ago
> Only among those that don't understand that, if this is a problem, then it is Canonical problem, not a Rust problem. (This is hard to express in a careful way where I'm confident of not offending anyone. Please take me at my word that I'm not trying to take sides in this at all.) The dominant narrative behind this pushback, as far as I can tell, is nothing to do with the Rust language itself (aside perhaps from a few fringe people who see the adoption of Rust as some kind of signal of non-programming-related politics, and who are counter-signaling). Rather, the opposition is to re-implementing "working" software (including in the sense that nobody seems to have noticed any memory-handling faults all this time) for the sake of seemingly nebulous benefits (like compiler-checked memory safety). The Rust code will probably also be more maintainable by Rust developers than the C code currently is by C developers given the advantages of Rust's language design. (Unless it turns out that the C developers are just intrinsically better at programming and/or software engineering; I'm pretty skeptical of that.) But most long-time C users are probably not going to want to abandon their C expertise and learn Rust. And they seem to outnumber the new Rust developers by quite a bit, at least for now.
- deleted 1y ago
  [deleted]
- inejge 1y ago
  > The dominant narrative behind this pushback, as far as I can tell, is nothing to do with the Rust language itself (aside perhaps from a few fringe people who see the adoption of Rust as some kind of signal of non-programming-related politics, and who are counter-signaling). Difficult to say with certainty, because it's easy to dress "political" resistance in respectable preference for stability. (Scare quotes because it's an amalgam in which politics is just a part.) Besides, TFA is Phoronix, whose commentariat is not known for subtlety on this topic. Replacing coreutils is risky because of the decades of refinement/stagnation (depending on your viewpoint) which will inevitably produce snags when component utilities interact in ways unforeseen by tests -- as has happened here. But without risk there's no reward. Of course, what's the reward here is subject to debate. IMO the self-evident advantage of a rewrite is that it's prima facie evidence of interest in using the language, which is significant if there's a dearth of maintainers for the originals. (The very vocal traditionalists are usually not in a hurry to contribute.)
  - subsistence234 1y ago
    Is there really a dearth of maintainers for the originals? They already work fine, no? To me it sounds a bit like: "Addition has become stagnant, so we need to re-implement it in higher category theory. Sure, 99% of even research mathematicians don't benefit from that re-implementation. But no risk no reward! If vocal traditionalists refuse to contribute to reinventing the wheel, maybe they're working on something that hasn't been refined/stagnated decades ago, but I won't take their perspective (that addition already works fine) seriously, unless they start re-implementing addition as well."
- mustache_kimono 1y ago
  > Rather, the opposition is to re-implementing "working" software I understand the argument, and its sounds good as far as most things go, but it misses an important fact: In OSS, you can and should find your own bliss. If you want to learn Rust, as I did, you can do it by reimplementing uutils' sort and ls, and fixing bugs in cp and mv, as I did. That was my bliss. OSS doesn't need to be useful to anyone. OSS can be a learning exercise or it can be simply for love of the game. The fact that Canonical wants to ship it, right now, simply makes them a little silly. It doesn't say a thing about me, or Rust, or Rust culture.
pornel 1y ago
This is more nuanced in Rust's case. Rust is trying to systemically improve safety and reliability of programs, so the degree to which it succeeds is Rust's problem. OTOH we also have people interpreting it as if Rust was supposed to miraculously prevent all bugs, and they take any bug in any Rust program as a proof by contradiction that Rust doesn't work.
- shikon7 1y ago
  It might be a bit of bad publicity for those who want to rewrite as much as possible in Rust. While Rust is not to blame, it shows that just rewriting something in Rust doesn't magically make it better (as some Rust hype might suggest). Maybe Ubuntu was a bit too eager in adopting the Rust Coreutils, caring more about that hype than about stability.
  - b_e_n_t_o_n 1y ago
    > Rust is not to blame Isn't that an unfalsifiable statement until the coreutils get written in another language and can be compared?
    - mustache_kimono 1y ago
      > Isn't that an unfalsifiable statement Sounds pretty axiomatic: Rust is not to blame for someone else's choice to ship beta software?
- mustache_kimono 1y ago
  > Rust is trying to systemically improve safety and reliability of programs, so the degree to which it succeeds is Rust's problem. GNU coreutils first shipped in what, the 1980s? It's so old that it would be very hard to find the first commit. Whereas uutils is still beta software which didn't ask to be representative of "Rust", at all. Moreover, GNU coreutils are still sometimes not compatible with their UNIX forebears. Even considering this first, more modest standard, it is ridiculous to hold this software to it, in particular.
b_e_n_t_o_n 1y ago
It's not about rust specifically, it's about replacing working software with rewrites and going from a code base written in a single language to one written in multiple.

AllegedAlec 1y ago

People have forgotten the sacred motto "Don't Break Userspace"

steveklabnik 1y ago
That slogan is about the kernel, not about user space programs.

SahAssar 1y ago

> And makes me wonder if this is gonna cause more pushback regarding the rust in the kernel movement. Does this have anything at all to do with the kernel?

shikon7 1y ago
No, and I expect kernel developers to be much more careful not to break anything with Rust rewrites.