I discovered and started using the silver searcher (ag) before ripgrep existed. I don't feel a strong need to switch for marginally faster search but with different command-line switches. Am I missing some killer feature here?
And perf depends on your haystack size. If you have lots of data to search, it's not hard to witness a 10x difference: https://news.ycombinator.com/item?id=45629904
As for features that ripgrep has that ag doesn't:
* Much better Unicode support. (ag's is virtually non-existent.)
* Pluggable preprocessors with --pre.
* Jujutsu support.
* ripgrep can automatically search UTF-16 data.
* ripgrep has PCRE2 support. ag only has PCRE1 (which was EOL'd years ago).
* ripgrep has a `-r/--replace` flag that lets you manipulate the output. I use it a lot instead of `sed` or `awk` (for basic cases) these days.
* ripgrep is maintained.
* ripgrep has multiline search that seemingly works much better.
* ripgrep can search files bigger than 2GB. ag seemingly can't.
* ag has lots of whacky bugs.
e.g.,
$ ag -c '\w{8,} Sherlock Holmes' sixteenth.txt
9
$ rg -c '\w{8,} Sherlock Holmes' sixteenth.txt
9
$ cat sixteenth.txt | rg -c '\w{8,} Sherlock Holmes'
9
$ cat sixteenth.txt | ag -c '\w{8,} Sherlock Holmes'
1
1
1
1
1
1
1
1
1
$ printf 'foo\nbar\n' | ag 'foo\s+bar'
$ printf 'foo\nbar\n' | rg -U 'foo\s+bar'
foo
bar
$ ag '\w+ Sherlock Holmes' full.txt
ERR: Skipping full.txt: pcre_exec() can't handle files larger than 2147483647 bytes.
And yes, ripgrep doesn't do any kind of Unicode normalization. Few tools do.
But that doesn't mean what I said was wrong. ripgrep has a whole host of Unicode features that ag doesn't have.
Read https://www.unicode.org/reports/tr10/#Searching what unicode has to say about string search, in opposition of the usual byte search grep tools.