1. 28
    Common *nix commands written in Rust rust unix gcollazo.com
  1.  

  2. 29

    Lots of these tools ostensibly being replaced actually have POSIX specifications, if the new tools don’t follow these they are not ‘common commands’ or ‘replacements’ but just a handy new program.

    1. 10

      This is just speaking at cross purposes. When someone comes up to me and says, “Thank you so much for ripgrep, it has replaced my usage of grep to find things,” should I therefore respond and say, “Well acksually, ripgrep isn’t a true replacement because it is not POSIX compatible”? No, I shouldn’t, because they didn’t lie. It really did replace their use of grep in the most literal sense. What they said was totally correct. You’re of course correct too, but in a different context.

      This FAQ item was written specifically because this communication snafu happens a lot: https://github.com/BurntSushi/ripgrep/blob/1980630f1770da3d7d392dc3b743d04018217e34/FAQ.md#posix4ever

      1. 5

        Well acksually the header of the article is:

        “Common *nix commands written in Rust”

        That would be like calling ripgrep “grep written in rust”. I’m sure we both agree that is not quite the right thing to say.

        Anyway, I agree with you in the general case, but sometimes it does a disservice to people really looking for drop in replacement to muddy the waters.

        1. 3

          That would be like calling ripgrep “grep written in rust”. I’m sure we both agree that is not quite the right thing to say.

          It is imprecise, but still correct in a lot of minds, because “grep” doesn’t have a precise meaning. How many times have you heard people say “grep” as nothing more than a synonym for “search”? I know I’ve heard it and used it that way.

          Besides, POSIX doesn’t have a monopoly on grep. It’s true that POSIX specifies a fairly limited set of behavior for a program called “grep,” but grep itself predates POSIX by many many years.

          1. 2

            Besides, POSIX doesn’t have a monopoly on grep.

            I agree more for grep than for some of the other tools listed.

          2. 2

            Offtopic, but I really dig the usage of “well, actually…” as a mark of nerd pride (as opposed to the original intention of the infamous article by de Icaza). It’s like when Feynman compared mathematics to masturbation and physics to sex, as if he wanted to disparage physics.

            1. 2

              “Common *nix commands written in Rust”

              That would be like calling ripgrep “grep written in rust”. I’m sure we both agree that is not quite the right thing to say.

              If we’re going to be pedantic, neither *nix (usually meaning unix like) nor unix is the same as POSIX, so the fact that there is a POSIX specification for a version of some of these *nix tools doesn’t seem particularly relevant. If the article was called, “Common POSIX commands written in Rust”, then I would expect them to adhere to the standards and behave as a drop in replacement.

              1. 1

                Except many of the common *nix commands listed do follow POSIX even though *nix does not mean POSIX.

          3. 1

            To me, this only matters if the behavior of the new program is a subset of POSIX, as opposed to a superset of POSIX. In short, did they do the work to implement all the behavior, or did they just do what they considered easy and left the rest off? The latter is probably a more straightforwards program, but the former tells us more about how the language handles somewhat nontrivial cases.

            1. 1

              Unfortunately, it probably also matters in practice if they’re a superset of the BSD or GNU behaviours. Most of these tools have a tiny spec in POSIX and a much larger set of functionality in the most widespread implementations. A lot of shell scripts depend on the extensions.

              With the exception of grep, none of these are performance critical in any metric other than startup time (grep does regex matching on huge amounts of text, everything else can slow down complex scripts if it takes too long to start, but the execution time is generally dwarfed by the startup time). I’d love to see these replaced by an AoT-compiled language that isn’t C.

          4. 5

            Is this the end of history for computer science?

            1. 6

              I sincerely hope an operating system with roots in the 1970s isn’t the end for CS….

              1. 4

                Soon we’ll all be using Linux at McDonalds.

              2. 4

                Interesting list! I’ve switched to many Rust variants of typical GNU utilities as well for various usability and speed reasons. A couple ones I use that I didn’t see in your list:

                1. 4

                  Am I the only who clicked the link and was surprised that this wasn’t about Nix the package manager?

                  1. 7

                    maybe? *nix used to refer to unix-like systems in general is really common.

                    1. 7

                      Probably. The asterisk notation, *nix, is a common way of referring to UNIX’y operating systems.

                    2. 4

                      Some other alternatives to top were mentioned here: https://lobste.rs/s/6yrlvf/comparing_alternatives_top_written_rust

                      I might prefer ytop over zenith, because in ytop the selection remains on the same process across updates.

                      1. 4

                        An actual in-progress rewrite in Rust of GNU coreutils (obviously, GNU != POSIX, but evidently the world has just stopped caring about anything that isn’t GNU on Linux anyway, much to my personal dismay) can be found at https://github.com/uutils/coreutils

                        1. 4

                          A lot of these are nifty implementations (I prefer exa to ls for example.) However, unless they are one-to-one compatible they shouldn’t be presented as replacements before considering any caveats.

                          1. 3

                            My biggest gripe is calling bat a cat replacement. It is not. bat is less replacement not cat. Also wc -l and tokei have completely different use cases and I literally never used one as a “replacement” of other.