[ncmncm]

Sorry, how does ripgrep save you tens of hours? I get that it is faster than regular grep, but that doesn't really answer the question; I don't find myself stalled waiting for grep. The only reasonable explanation would be something ripgrep does that grep actually doesn't. I could try to guess, but have no confidence I would guess right.

[crdrost]

1. Available on Windows without WSL, possibly the biggest time saver for those affected

2. Auto ignores .gitignore files, so does not search node_modules or build/ etc., huge noise reduction there.

3. -t/-T gates on file extension which is a very nice feature, again signal to noise

4. The combo of speed and the above and the recursive-by-default mean that you search much larger corpuses by default, like “all the microservices in the cluster” or “my entire home dir”, because you know it's some .xml file mentioning “jackson” where you saw this config you need before.

5. For some reason I never remember which regex features are grep vs egrep, so I end up just testing on a bunch of strings to see if I have to like backslash the plus operator or whatever. With rg it's like “oh this is going to have the same syntax as JS regex.”

6. Unicode compatibility by default could save you that sort of time maybe on specific workloads?

[3np]

7. Options like -g, --max-depth, and --max-filesize make chaining with `find` or (trigger warning) grepping your grep output redundant.

[thelibrarian]

Totally anecdotal, but I have found ripgrep orders of magnitude faster than grep when searching a large corpus of data (in my case, many multi-hundred megabyte to gigabyte XML files). As in, ripgrep completed the search in seconds, grep took multiple minutes. I'm sure I could have done some research to optimise/parallelise grep, but ripgrep worked doing the "dumb" search.