[eigenlicht]

- fd: an improved find Depends on what you need to do, at least without constructing a pipeline like it's 1990 (modern..), probably on your age, and how much you suck at typing. I have it installed as well, but most of the time still use find and not just in scripts which hopefully is a no-brainer. Some rather weird decisions went into that iteration, or call it taste if you prefer. Even the name is a joke honestly. But what in and out of Rust isn't. Re-inventing the wheel, ok. But then why not, err, also improve on it?

- hexyl: a better xxd Like what?!

- ripgrep: a cornerstone of my workflow, an improved grep No, it's a by default recursive grep which grep emphatically isn't, wasn't and never aimed to be. It has many, many more features, is bigger, newer, shinier and (yes) a bit slower. But that's ok, I use it too where it makes sense, as usual. An improved silversearcher, maybe that!

I'm barely using anything of the mentioned. But then I hate colors, and when I want to see nice pictures I'm off to the movies. At least your definition of modern is actually funny.

[burntsushi]

> It has many, many more features, is bigger, newer, shinier and (yes) a bit slower.

Can you show a common case where ripgrep is meaningfully slower than grep?

Here are a few common cases where ripgrep is meaningfully faster than GNU grep 3.11 on Linux.

The setup:

    $ cd /dev/shm
    $ curl -LO 'https://burntsushi.net/stuff/OpenSubtitles2018.raw.sample.en.gz'
    $ gunzip OpenSubtitles2018.raw.sample.en.gz

A simple case:

    $ time rg -c 'Sherlock Holmes' OpenSubtitles2018.raw.sample.en
    502

    real    0.102
    user    0.056
    sys     0.046
    maxmem  903 MB
    faults  0

    $ time LC_ALL=C grep -c 'Sherlock Holmes' OpenSubtitles2018.raw.sample.en
    502

    real    0.378
    user    0.255
    sys     0.122
    maxmem  21 MB
    faults  0

A case with multiple substrings:

    $ time rg -c -e 'Sherlock Holmes' -e 'John Watson' -e 'Irene Adler' -e 'Professor Moriarty' OpenSubtitles2018.raw.sample.en
    628

    real    0.128
    user    0.077
    sys     0.050
    maxmem  903 MB
    faults  0

    $ time LC_ALL=C grep -c -e 'Sherlock Holmes' -e 'John Watson' -e 'Irene Adler' -e 'Professor Moriarty' OpenSubtitles2018.raw.sample.en
    628

    real    0.580
    user    0.516
    sys     0.063
    maxmem  21 MB
    faults  0

You can run the `rg` commands with `--no-mmap` to get slightly slower but roughly similar times but using standard `read` syscalls instead of file-backed memory maps.

I chose these cases because they represent common and simple queries. And, specifically, it's searching a single text file. There isn't anything involving parallelism or skipping files or recursive search or whatever.

[llimllib]

For me, fd is as better than find as ripgrep is to grep

The main benefits are:

- it skips ignored and hidden files by default

- it uses modern regular expressions

- it has a more sane UI (`find . -iname '*.txt'` -> `fd -g '*.txt'`)

I do use it in scripts as long as I know they're going to run in a context where it's available, ex: https://github.com/llimllib/personal_code/blob/c3d33b4d95f89...