5 ms·

Code is cleaner too, fewer hacks than typical Coreutils code. You get the benefits of BSD style clean code while still having high performance because there are

Code is cleaner too, fewer hacks than typical Coreutils code. You get the benefits of BSD style clean code while still having high performance because there are clear functional boundaries and specific features are compartmentalized in modules and dependencies. Systems programming has finally caught up to 30 years of advances in software engineering. Long live the Rust Evangelism Strike force. Finally Apache/Linux is now possible.

riffraff 4y ago
Why Apache/Linux? Is uutils part of the Apache foundation?
- allendoerfer 4y ago
  OP is referring to the license.
  - riffraff 4y ago
    But that's MIT not Apache
    - earthling8118 4y ago
      It's extremely common for Rust projects to be licensed with both of them
      - riffraff 4y ago
        makes sense, thanks.
yjftsjthsd-h 4y ago
> Code is cleaner too, fewer hacks than typical Coreutils code I was under the impression that GNU Coreutils is weird/hacky in implementation because of 3 reasons (in no particular order): 1. Performance, 2. Portability, 3. To make it blatantly obvious that it's not copied from proprietary UNIX™ code. The last point is... unfortunate at this point in time, if unavoidable given the history. For performance, I'll be interested to see how it goes; Rust should help things compose better and lend itself to saner structuring, but the harder you lean into performance the more unavoidable complexity you incur, so it'll be interesting to find out how well new implementations can do. And portability, I suspect, will be the dump stat of any new implementation. Sure, it'll work on Linux, on x86 and ARM. Beyond that... I mean, last time I looked Rust didn't even support as many CPU architectures as Linux, let alone as many OSs as GNU does. I'm not sure if that's a problem or not; so far the precedent seems to be to just break anything unusual and not care (looking at you, Python cryptography), which is a win for the masses and unfortunate for everything else.
- carlmr 4y ago
  >the harder you lean into performance the more unavoidable complexity you incur, so it'll be interesting to find out how well new implementations can do While true, especially with string heavy processing, using the borrow checker with CoW structures to cleanly save allocations does more for boosting performance than some hacky C++ code where you never know when it breaks because there are no guarantees on mutability and lifetime of variables.
snvzz 4y ago
[flagged]

riffraff 4y ago

Why Apache/Linux? Is uutils part of the Apache foundation?

allendoerfer 4y ago
OP is referring to the license.
- riffraff 4y ago
  But that's MIT not Apache
  - earthling8118 4y ago
    It's extremely common for Rust projects to be licensed with both of them
    - riffraff 4y ago
      makes sense, thanks.

yjftsjthsd-h 4y ago

> Code is cleaner too, fewer hacks than typical Coreutils code I was under the impression that GNU Coreutils is weird/hacky in implementation because of 3 reasons (in no particular order): 1. Performance, 2. Portability, 3. To make it blatantly obvious that it's not copied from proprietary UNIX™ code. The last point is... unfortunate at this point in time, if unavoidable given the history. For performance, I'll be interested to see how it goes; Rust should help things compose better and lend itself to saner structuring, but the harder you lean into performance the more unavoidable complexity you incur, so it'll be interesting to find out how well new implementations can do. And portability, I suspect, will be the dump stat of any new implementation. Sure, it'll work on Linux, on x86 and ARM. Beyond that... I mean, last time I looked Rust didn't even support as many CPU architectures as Linux, let alone as many OSs as GNU does. I'm not sure if that's a problem or not; so far the precedent seems to be to just break anything unusual and not care (looking at you, Python cryptography), which is a win for the masses and unfortunate for everything else.

carlmr 4y ago
>the harder you lean into performance the more unavoidable complexity you incur, so it'll be interesting to find out how well new implementations can do While true, especially with string heavy processing, using the borrow checker with CoW structures to cleanly save allocations does more for boosting performance than some hacky C++ code where you never know when it breaks because there are no guarantees on mutability and lifetime of variables.

snvzz 4y ago

[flagged]