Author of ripgrep here. There are two ways to talk about "speed." On the one hand, we have the "speed" that is associated with the user experience. That is, gi

Author of ripgrep here. There are two ways to talk about "speed." On the one hand, we have the "speed" that is associated with the user experience. That is, given some problem the user cares about, how fast can you solve it? On the other hand, we have the "speed" that is associated with doing precisely the same task and measuring which tool does it faster. ripgrep is generally faster at both of those things, but it's the former where it really shines: $ git remote -v origin git@github.com:nwjs/chromium.src (fetch) origin git@github.com:nwjs/chromium.src (push) $ git rev-parse HEAD 5d32cab40f738932eddc017980e2e409c5abef2c $ time rg 'Xvfb and Openbox' | wc -l 1 real 0.289 user 1.526 sys 1.731 maxmem 87 MB faults 0 $ time grep -r 'Xvfb and Openbox' ./ | wc -l 1 real 5.405 user 3.489 sys 1.890 maxmem 11 MB faults 0 (I ran these commands multiple times each until the times stabilized. i.e., The directory tree is in cache.) We're talking about an order of magnitude improvement here to get the same results. And not just in a "ripgrep took 10ms and grep took 100ms, but both are fast enough" sense. This is the difference between "near instant results" and "this is taking annoyingly long." Now of course, from the perspective of the second idea of speed, this isn't an apple-to-apples comparison. GNU grep is actually searching a lot more data here. We can make ripgrep search the same amount of data as GNU grep quite easily: $ time rg -uuu 'Xvfb and Openbox' | wc -l 1 real 2.538 user 2.570 sys 3.017 maxmem 72 MB faults 0 So, still a big improvement over GNU grep, but it's not quite as jaw dropping. The important bit here is that a lot of people care about the improvement at the UX level. You can, for example, get a fair bit of improvement with GNU grep with some extra flags: $ time grep -r --exclude-dir='.git' 'Xvfb and Openbox' ./ | wc -l 1 real 1.630 user 0.781 sys 0.826 maxmem 11 MB faults 0 And now you've got to shove that stuff into an alias or a wrapper script. Which... is fine. I did it for a very long time before I wrote ripgrep. I had a whole bunch of aliases and wrapper scripts, many of which were specific to certain types of projects. But once I built ripgrep, all of those aliases and wrapper scripts went away. Because ripgrep's heuristics for smart filtering by default subsumed all of them. Finally, it's worth pointing out that ripgrep isn't intended to replace grep. It literally can't. It's not POSIX compatible. So if you're writing shell scripts and care more about portability, then 'grep' is a fine choice. Indeed, I still use 'grep' for precisely that purpose. See: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#posix4ever https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...