4 ms·

I think that is the goal of uutils. https://uutils.github.io/ https://uutils.github.io/

cocoa19 1y ago
I hope some are improved too. The performance boost in tools like ripgrep and tokei is insane compared to the tools they replace (grep and cloc respectively).
- egorfine 1y ago
  I absolutely hate it when people call their tools a "replacement" for something that is part of core standards, something, that did just fine for decades. ripgrep is an excellent tool. But it's not a grep replacement. And should not ever be.
  - mprovost 1y ago
    The GNU utils were a replacement for the BSD utils which were a replacement for the original AT&T utils. Every replacement added new functionality and improvements, and every time someone complained that they didn't stick closer to the thing they replaced. Looking specifically at grep, there used to be new versions like egrep and fgrep that added functionalities beyond standard grep's, but those were eventually pulled into "standard" grep (GNU or BSD). If we stuck with standards we'd all still be using the Bourne shell. The GNU utilities have been around long enough that they feel like the standard now, but I'm glad that we're coming into a new phase of innovation in command-line utilities. And this didn't start with Rust - the new generation of search utilities started with ack (Perl) and then ag (C).
    - egorfine 1y ago
      > which were a replacement for the You have a point here. I have to agree. "X but rewritten in Z" is a terrible marketing, though. Makes me instantly want to hate the tool and its authors. (Love rust. Hate the vibe).
      - mprovost 1y ago
        Why the hate? It's a genuine question. When you rewrite something, you need to justify the effort somehow. The GNU coreutils started out as "the BSD utilities, but with the GPL!".
        egorfine 1y ago
        Because the reimplementation authors skip all the complexities of designing the tool in the first place while getting right to the fun part (which is coding), and then they get to call themselves authors of a well known infrastructure tool. Compare "I have typed a setuid() wrapper in rust" vs "I'm the author of sudo-rs".
      - scripturial 1y ago
        It’s a rust crate designed to be a native rust replacement for a rust c wrapper crate. It’s faster and easier to link to in rust projects. How would you even tell people you made a better rust crate without using the word “rust?”
        egorfine 1y ago
        Why not spend the efforts to speed up the real zlib? So that the whole world actually gets to spin a bit faster. Rust folks are claiming excellent interoperability with C binaries. Why the need for a rewrite then?
        swiftcoder 1y ago
        Maybe because the speed up is easier to attain in a language where you aren't constantly worrying about introducing bugs? Maybe development is easier in a language with more modern tooling? Interoperability runs both ways, everyone currently taking a dependency on the C library can swap in the rust library in its place and see the same benefits
        throwawaymaths 1y ago
        you would say "rewritten FOR rust" instead of "rewritten IN rust".
    - egorfine 1y ago
      > we'd all still be using the Bourne shell Please forgive me my ignorance but what's wrong with bash? I'm still using it on all servers and workstations, I constantly write scripts for it, some fairly complex. It's not an obsolete project and it looks like a mainstream shell for me. Am I wrong? Update: yeah, I realize now that this was about the original Bourne Shell, not bash.
      - dagw 1y ago
        Bash is not Bourne, and that's the point. Bash is the Bourne Again Shell, a shell written to improve and replace the Bourne shell in the GNU ecosystem. Modern bash is a huge improvement over the original Bourne shell and I'm convinced you use bash only feature basically every day, and would be very annoyed if someone forced you to use the actual Bourne shell
        egorfine 1y ago
        Ah, right! I do remember the original Bourne Shell, though. I wouldn't like to get back to using it. Though I might agree provided I get as many years of my age back.
      - mprovost 1y ago
        Bash isn't the Bourne shell (sh)! It's a replacement (Bourne Again Shell). But it's interesting that the replacement has become so entrenched that folk assume that it was the original.
        egorfine 1y ago
        Yeah, got it now lol
    - hulitu 1y ago
      > If we stuck with standards we'd all still be using the Bourne shell or Korn shell.
  - burntsushi 1y ago
    I didn't call ripgrep a replacement. Other people do. Because it does actually replace their usage of grep in some or all cases, depending on their usage patterns. https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#can-ripgrep-replace-grep https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#can...
  - dagw 1y ago
    And should not ever be. Those "core standards" that you talk about didn't spring fully formed from the earth. They came about from competition and beating out and replacing the old "core standards" that lots of people argued very strongly for should not ever be replaced. When I was starting out my career I was told by experienced people that I should not learn to rely on the GNU tool features, since they're far from ubiquitous and probably won't be installed on most systems I'll be working on.
    - egorfine 1y ago
      That's right and still true: GNU tools are still not ubiquitous on mainstream computers. And I'm not talking about that Ultrix box still churning. For example the latest macOS carries bsd tar, so.
  - deleted 1y ago
    [deleted]
- jelder 1y ago
  I hadn't heard of tokei before, so I tried it on a small project of mine. Tokei _finishes_ before cloc can print its help text. I wrote this post in less time than it took `cloc .` to count all the files in my project, probably because it doesn't know to ignore `target/`.
  - arp242 1y ago
    > Tokei _finishes_ before cloc can print its help text. cloc is a Perl script, so it has the interpreter startup time.
coldpie 1y ago
1) This is a cool project and I wish them success. It would be really cool if these became the default utilities some day soon. 2) I think the MIT license was a mistake. These are often cloning GNU utilities, so referencing GNU source in its original language and then re-implementing it in Rust would be the obvious thing to do. But porting GPL-licensed code to an MIT licensed project is not allowed. Instead, the utilities must be re-implemented from scratch, which seems like a waste of effort. I would be interested in doing the work of porting GNU source to Rust, but I'm not interested in re-writing them all from scratch, so I haven't contributed to this project.
- hueho 1y ago
  Plenty of people dislike the perceived bload in GNU utils - for them a rewrite from scratch is a feature, not a bug.
- monster_truck 1y ago
  What's the point of mentioning you suspect it is happening other than as a dig at them?
  - coldpie 1y ago
    You're 100% right. I removed it.
- Scuds 1y ago
  "Seems like a waste of effort" in a vacuum yes, but 1 - GNU utilities is ancient crufty #IFDEF'd C that's been in maintenance mode for decades. You want code to handle quirks of Tru64 and Ultrix? You got it. 2 - Waving your hands around 'the community will take care of it' is magical thinking. C developers don't grow on trees. C tooling is kinda weird and doesn't resemble anything modern - good luck finding enough VOLUNTEER C developers to make your goals happen.

I hope some are improved too. The performance boost in tools like ripgrep and tokei is insane compared to the tools they replace (grep and cloc respectively).

egorfine 1y ago
I absolutely hate it when people call their tools a "replacement" for something that is part of core standards, something, that did just fine for decades. ripgrep is an excellent tool. But it's not a grep replacement. And should not ever be.
- mprovost 1y ago
  The GNU utils were a replacement for the BSD utils which were a replacement for the original AT&T utils. Every replacement added new functionality and improvements, and every time someone complained that they didn't stick closer to the thing they replaced. Looking specifically at grep, there used to be new versions like egrep and fgrep that added functionalities beyond standard grep's, but those were eventually pulled into "standard" grep (GNU or BSD). If we stuck with standards we'd all still be using the Bourne shell. The GNU utilities have been around long enough that they feel like the standard now, but I'm glad that we're coming into a new phase of innovation in command-line utilities. And this didn't start with Rust - the new generation of search utilities started with ack (Perl) and then ag (C).
  - egorfine 1y ago
    > which were a replacement for the You have a point here. I have to agree. "X but rewritten in Z" is a terrible marketing, though. Makes me instantly want to hate the tool and its authors. (Love rust. Hate the vibe).
    - mprovost 1y ago
      Why the hate? It's a genuine question. When you rewrite something, you need to justify the effort somehow. The GNU coreutils started out as "the BSD utilities, but with the GPL!".
      - egorfine 1y ago
        Because the reimplementation authors skip all the complexities of designing the tool in the first place while getting right to the fun part (which is coding), and then they get to call themselves authors of a well known infrastructure tool. Compare "I have typed a setuid() wrapper in rust" vs "I'm the author of sudo-rs".
    - scripturial 1y ago
      It’s a rust crate designed to be a native rust replacement for a rust c wrapper crate. It’s faster and easier to link to in rust projects. How would you even tell people you made a better rust crate without using the word “rust?”
      - egorfine 1y ago
        Why not spend the efforts to speed up the real zlib? So that the whole world actually gets to spin a bit faster. Rust folks are claiming excellent interoperability with C binaries. Why the need for a rewrite then?
        swiftcoder 1y ago
        Maybe because the speed up is easier to attain in a language where you aren't constantly worrying about introducing bugs? Maybe development is easier in a language with more modern tooling? Interoperability runs both ways, everyone currently taking a dependency on the C library can swap in the rust library in its place and see the same benefits
      - throwawaymaths 1y ago
        you would say "rewritten FOR rust" instead of "rewritten IN rust".
  - egorfine 1y ago
    > we'd all still be using the Bourne shell Please forgive me my ignorance but what's wrong with bash? I'm still using it on all servers and workstations, I constantly write scripts for it, some fairly complex. It's not an obsolete project and it looks like a mainstream shell for me. Am I wrong? Update: yeah, I realize now that this was about the original Bourne Shell, not bash.
    - dagw 1y ago
      Bash is not Bourne, and that's the point. Bash is the Bourne Again Shell, a shell written to improve and replace the Bourne shell in the GNU ecosystem. Modern bash is a huge improvement over the original Bourne shell and I'm convinced you use bash only feature basically every day, and would be very annoyed if someone forced you to use the actual Bourne shell
      - egorfine 1y ago
        Ah, right! I do remember the original Bourne Shell, though. I wouldn't like to get back to using it. Though I might agree provided I get as many years of my age back.
    - mprovost 1y ago
      Bash isn't the Bourne shell (sh)! It's a replacement (Bourne Again Shell). But it's interesting that the replacement has become so entrenched that folk assume that it was the original.
      - egorfine 1y ago
        Yeah, got it now lol
  - hulitu 1y ago
    > If we stuck with standards we'd all still be using the Bourne shell or Korn shell.
- burntsushi 1y ago
  I didn't call ripgrep a replacement. Other people do. Because it does actually replace their usage of grep in some or all cases, depending on their usage patterns. https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#can-ripgrep-replace-grep https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#can...
- dagw 1y ago
  And should not ever be. Those "core standards" that you talk about didn't spring fully formed from the earth. They came about from competition and beating out and replacing the old "core standards" that lots of people argued very strongly for should not ever be replaced. When I was starting out my career I was told by experienced people that I should not learn to rely on the GNU tool features, since they're far from ubiquitous and probably won't be installed on most systems I'll be working on.
  - egorfine 1y ago
    That's right and still true: GNU tools are still not ubiquitous on mainstream computers. And I'm not talking about that Ultrix box still churning. For example the latest macOS carries bsd tar, so.
- deleted 1y ago
  [deleted]
jelder 1y ago
I hadn't heard of tokei before, so I tried it on a small project of mine. Tokei _finishes_ before cloc can print its help text. I wrote this post in less time than it took `cloc .` to count all the files in my project, probably because it doesn't know to ignore `target/`.
- arp242 1y ago
  > Tokei _finishes_ before cloc can print its help text. cloc is a Perl script, so it has the interpreter startup time.

coldpie 1y ago

1) This is a cool project and I wish them success. It would be really cool if these became the default utilities some day soon. 2) I think the MIT license was a mistake. These are often cloning GNU utilities, so referencing GNU source in its original language and then re-implementing it in Rust would be the obvious thing to do. But porting GPL-licensed code to an MIT licensed project is not allowed. Instead, the utilities must be re-implemented from scratch, which seems like a waste of effort. I would be interested in doing the work of porting GNU source to Rust, but I'm not interested in re-writing them all from scratch, so I haven't contributed to this project.

hueho 1y ago
Plenty of people dislike the perceived bload in GNU utils - for them a rewrite from scratch is a feature, not a bug.
monster_truck 1y ago
What's the point of mentioning you suspect it is happening other than as a dig at them?
- coldpie 1y ago
  You're 100% right. I removed it.
Scuds 1y ago
"Seems like a waste of effort" in a vacuum yes, but 1 - GNU utilities is ancient crufty #IFDEF'd C that's been in maintenance mode for decades. You want code to handle quirks of Tru64 and Ultrix? You got it. 2 - Waving your hands around 'the community will take care of it' is magical thinking. C developers don't grow on trees. C tooling is kinda weird and doesn't resemble anything modern - good luck finding enough VOLUNTEER C developers to make your goals happen.