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...

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

    $ 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

    $ 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

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.