
Feature comparison of ack, ag, git-grep, GNU grep and ripgrep - infodroid
https://beyondgrep.com/feature-comparison/
======
infodroid
The chart was created by Andy Lester, the creator of ack, who thinks that more
open source projects should point to their "competing" projects because it's
not really a competition: [http://blog.petdance.com/2018/01/02/the-best-open-
source-pro...](http://blog.petdance.com/2018/01/02/the-best-open-source-
project-for-someone-might-not-be-yours-and-thats-ok/)

~~~
SamPutnam
_Emphasis_ mine-

Excerpt: "Some might say that ag and ripgrep and any of the other tools I list
on beyondgrep.com are competing projects, but I think that way of thinking is
wrong. It’s only a competition if you see it as a competition. I’m not
competing against anyone for anything: Clicks, dollars, popularity, etc. If
someone uses ripgrep instead of ack, it doesn’t hurt me. _It’s the difference
between an abundance vs. scarcity view of the world. I choose abundance. I
think most of us who work in open source do, too._ "

I never thought I would see the confluence of the "woo-woo" space abundance
mindset and a blog post about an open source command-line utility. I must say
I am intrigued.

If this explanatory medium doesn't substantiate the reasonability of a mindset
of abundance in the minds of programmers, I don't know what ever will.

~~~
bringtheaction
What is woo-woo space?

~~~
girvo
I’d wager they’re talking about the whole “The Secret” abundance mentality
thing. “Believe and you shall receive... somehow”. That sort of interesting
New Age stuff. I put no credence in it myself in terms of their stronger
claims, but hey, CBT reminds me of it in a lot of ways and helped cure my
depression.

~~~
petdance
Author here. I don't know about "The Secret" other than it being an Oprah
thing, what, ten years ago?

Abundance vs. scarcity has nothing to do with “Believe and you shall
receive... somehow”.

Scarcity thinking means that you fear giving people credit, and letting others
have success. You fear that praising others makes you seem weak. You think
that if someone uses a different open source project than yours, that you or
your project suffers. You might not even be aware of the thinking. You might
just feel it reflexively.

Abundance thinking says that there is more than enough praise to go around. It
says that your success doesn't hurt me in mine (unless in some tangible way it
does). It says that you can use ag and I can use ack and Susan can use ripgrep
and it's all good.

In this specific case, abundance says that I, as the creator of ack, don't
need to own the "market". In fact, the creation of other tools only helps ack.
It gives the ack team ideas for things we can implement in ack. Who am I to
think that I'm the only one with good ideas?

It gives our users a wider choice of tools. I put my work out there publicly
to help people. Why would I not want them to have a variety to choose from?

That's abundance vs. scarcity.

~~~
burntsushi
Well said. :-)

I've added a link to your feature comparison table to my REAMDE[1]. Thanks
again for putting it together!

[1] - [https://github.com/BurntSushi/ripgrep#feature-
comparison](https://github.com/BurntSushi/ripgrep#feature-comparison)

~~~
fho
Involuntary Neil Stephenson reference :-)

------
rozim
The table is misleading isn't it? It seems to imply that rg can't work
recursively, but [1] states "..ripgrep defaults to recursive directory
search...". I understand that the table might mean that rg doesn't have a flag
to enable recursive search, but surely we care about features more than
flags...

[1] [https://github.com/BurntSushi/ripgrep#why-should-i-use-
ripgr...](https://github.com/BurntSushi/ripgrep#why-should-i-use-ripgrep)

~~~
infodroid
The table doesn't yet distinguish between lacking a command line flag due to
absence of a feature vs due to the feature being the default. This is similar
to the situation with case-sensitive search in GNU grep, which ends up with a
blank cell even though it is the default. See:
[https://github.com/beyondgrep/website/issues/72](https://github.com/beyondgrep/website/issues/72)

It's a fair criticism but I don't think it is designed to be misleading.

~~~
fragmede
Maybe not _designed_ to be misleading, but misleading nonetheless. For `grep`,
`grep -i needle` is (approximately) equal to `ack/ag needle`, but looking at
the table I wouldn't think grep supports case sensitivity.

~~~
petdance
I've updated the phrasing so it says "Re-enable case-sensitive search over
case-insensitve or smart-case search".

------
zellyn
Here to plug using `--passthru`/`--passthrough`: it will print all lines, but
highlight matches. I often do things like this to watch an output log, but
highlight all entries with the string PLUGH in them:

    
    
       tail -F output.log | ag --passthrough '.*PLUGH.*'

~~~
whacker
The equivalent in grep is '\--line-buffered'.

~~~
richardwhiuk
huh?

~~~
whacker
I mean you can use grep as a filter for tail -f output.

------
memco
Seems pretty comprehensive. One confusing thing I found was these two: "Don't
respect ignore files (.gitignore, .ignore, etc)" vs "Skip rules found in VCS
ignore files (.gitignore, .hgignore, etc)"

Aren't those the same thing? Shouldn't they be grouped for better comparison?

------
the_mitsuhiko
I’m stuck with rg right now because it’s the only ine which correctly handles
gitignore files. Generally quite happy with it but I wish it could also use a
more powerful regex engine for some less common cases.

Most annoying thing is that $ does not work with windows newlines.

~~~
jrochkind1
ack doesn't do git ignore right? The matrix suggests it does, and I thought it
did, but I don't use it routinely.

~~~
the_mitsuhiko
It supports a subset but not a very good one. At least it fails to handle
leading slashes.

------
markild
Not exactly sure what it is, but I really like this presentation format.

Thank you, have been trying to motivate myself to switch to ack/ag for a
while. This seems like it might be what I needed.

~~~
nolemurs
Consider just switching to ripgrep instead. It's faster, and the default flags
and interface are more thoughtful. This chart may make it seem less feature
rich, but most of the 'features' it's missing are thing you'll never need, or
things that your shell should be responsible for ("Pipe output through a pager
or other command"?).

The only serious feature you might miss is lookahead/lookbehind in regexes -
that's missing by design since if you want guaranteed linear time search you
can't have those.

~~~
derwiki
> "Pipe output through a pager or other command"

I really like the discussion that lead to the decision of never including a
pager:

[https://github.com/BurntSushi/ripgrep/issues/86](https://github.com/BurntSushi/ripgrep/issues/86)

------
arca_vorago
The one thing I wish more of these comparison tables had was licensing info,
so for those like me who are curious:

1\. GNU grep - GPLv3+

2\. ack - Artistic License v2.0

3\. ag (aka silver searcher) - Apache License 2.0

4\. git-grep - GPlv2+/LGPLv2.1+

5\. rg - MIT license

So with maybe the exception of rg, all are gpl compatible, that's great news.

~~~
burntsushi
Anything that is permissively licensed (like ripgrep) is generally GPL
compatible.[1] Note also that ripgrep is dual licensed under the Unlicense or
the MIT license, both of which are explicitly GPL compatible according to [1].

[1] - [https://www.gnu.org/licenses/license-
list.en.html](https://www.gnu.org/licenses/license-list.en.html)

------
fphilipe
A nice feature of ag is the ability to limit the search to a certain file
type. E.g. to only search ruby files: _ag --ruby foo_.

To see a list of supported types and the matching file extensions: _ag --list-
file-types_.

Just checked and rg does have something similar, but you need to specify the
type as an argument to a flag: _rg --type ruby foo_.

~~~
okdana
You can shorten it with -t: -tc, -tphp, -truby, -tsh. Then it's actually the
same amount of characters as with ag.

~~~
masklinn
And has the advantage of being pluggable rather than a hard-coded list of file
types (though IIRC ack has a configuration file whereas with rg you need to
use an alias to set up new types for every invocation).

~~~
petdance
ack has a configuration file, and it's extremely flexible, including the
ability to check shebang lines. If you have a shell script without an
extension, it's the only way to know what language it is.

------
adamnemecek
This chart doesn't compare speed. Until rg, I didn't grep much because I
generally search through a lot of files. rg cuts through them in no time.

~~~
andersonfreitas
The `sift` [1] tool presents a performance comparison, but not against `rg`.

[1] [https://sift-tool.org/performance](https://sift-tool.org/performance)

~~~
BlackFingolfin
Unfortunately that page does not say when the comparison was made, and which
version of each tool was tested. Also, which "grep" is that? I assume GNU
grep? There are others, though...

All in all, it'd still be nice to have a more comprehensive performance
comparison page, which gets regularly updated. Bonus points if it shows how
speed changes over time, similar to
[http://speed.pypy.org](http://speed.pypy.org) (the code for that is
available, by the way).

Wishful thinking, I know, but hey, who knows... :-)

~~~
bradknowles
There is more detail available in the benchmark runs at
[https://github.com/BurntSushi/ripgrep/tree/master/benchsuite...](https://github.com/BurntSushi/ripgrep/tree/master/benchsuite/runs)

However, those are from 2016, and so it's hard to tell what might have changed
in the meanwhile.

~~~
burntsushi
The benchmark suite can be run by anyone:
[https://github.com/BurntSushi/ripgrep/blob/master/benchsuite...](https://github.com/BurntSushi/ripgrep/blob/master/benchsuite/benchsuite)

I re-ran them :-)
[https://github.com/BurntSushi/ripgrep/tree/master/benchsuite...](https://github.com/BurntSushi/ripgrep/tree/master/benchsuite/runs/2018-01-08-archlinux-
cheetah)

TL;DR ripgrep has gotten faster in important areas since the initial set of
benchmarks (the proper comparison there would be
[https://github.com/BurntSushi/ripgrep/tree/master/benchsuite...](https://github.com/BurntSushi/ripgrep/tree/master/benchsuite/runs/2016-09-22-archlinux-
cheetah)). The key reasons why are because it grew a parallel directory
traverser, and its line counting got vectorized courtesy of the bytecount[1]
crate. ucg has gotten a little faster in some cases, but the general
conclusion of "ripgrep is the fastest" is still correct.

[1] -
[https://github.com/llogiq/bytecount](https://github.com/llogiq/bytecount)

~~~
bradknowles
Thank you for re-running them. You saved me the trouble. ;)

I would be curious to see ack get into the test suite, however. Even if it is
much slower, I'd like to see the results.

And I'd be very curious to hear your reasoning for the different results in
the subtitles_ru test cases -- why is rg returning radically different numbers
of lines as compared to the other tools?

Thanks!

~~~
petdance
ack will always be slower than ripgrep, but it shouldn't be as slow as it is
in burntsushi's tests. In his tests, he's showing run times where ack takes
25x as long to run as ripgrep, and ack shouldn't be NEARLY that slow.

We think that there's something weird about his Perl installation that is
making it so slow, but we haven't been able to figure it out.

Here's the ticket:
[https://github.com/beyondgrep/ack3/issues/42](https://github.com/beyondgrep/ack3/issues/42)

If you have any insight, we'd love to have it. We've been stumped, as you'll
see if you read through the issue history.

~~~
burntsushi
I will dig back into this and see if I can figure it out. If you look at the
recent commit history for ripgrep, you'll see I updated the timings for ack on
my benchmark in my README. I have no explanation for it, but ack isn't as slow
as it was when I went through this before.

Anyway, my Perl installation is the standard one on Archlinux. I will try on
other systems.

------
mbroshi
Nice feature-level comparison.

Don't know how you'd pull it off in the current tabular format, but would be
great to include some of the UX side of things: For example, I use rg almost
exclusively because it has an easy-to remember syntax (`rg search-string` is a
recursive search), attractively colored and well-organized output, and seems
much faster compared to other tools in my use cases.

------
nothrows
as a long time user of `find . -name "*.foo" -exec grep -Hin {} \;` moving to
ack has been great! I love the syntax and the speed and the fact that it
actually respects your ignore files. ripgrep is great too. ag on the other
hand is recommended by everyone but doesn't seem to respect ignores or
understand modern ignore syntax. give it a pass.

[https://github.com/ggreer/the_silver_searcher/issues/385](https://github.com/ggreer/the_silver_searcher/issues/385)

its been over 4 years... its had its chance.

~~~
xorcist
Spawning a separate grep for each file? That's terribly inefficient. At least
use xargs which will run one process on as many files as possible.

But you know there's a -r for recursive, right? And unless you are using some
historic relic of grep that is not GNU or BSD and doesn't understand the
--include option you can just do:

grep -rin "needle" \--include "*.foo" .

~~~
aidenn0
I use something along the lines of

    
    
        find . -iname '.*' -prune -o -iname '*.foo' -exec grep needle {} +
    

I don't want to have to learn 10 different command syntaxes for walking
directory trees, so find works well. The "+" terminator of find's exec is
similar to xargs, but preserves the flexibility of find's exec.

------
satish-setty
Seems everybody here has switched to rg but I haven't because it's not
available in Debian repos (yet) unlike ack/ag. So, do such folks use Arch or
just download a pre-built binary ? How about updating rg when a new version is
out ?

~~~
cesarb
The easiest way: first, install rust and cargo, either through your
distribution, or thorough rustup if your distribution doesn't have it yet.
Then run "cargo install -f ripgrep". It'll download the source code, build,
and install to ~/.cargo/bin, which rustup adds to $PATH for you by default.

Edit: the "-f" in the "cargo install" command is for updating; without the -f,
it refuses to install over an already installed version. The first time you
install, you can omit the -f.

~~~
burntsushi
Note that if you install Rust through Debian, it likely won't be new enough to
compile the latest version of ripgrep. I believe Debian packages Rust 1.14,
and the last version of ripgrep to work on Rust 1.14 was 0.5.2. So, `cargo
install --vers 0.5.2 ripgrep` might be what you want on Debian.

~~~
glandium
Debian stable has 1.14, but Debian testing has 1.22.1.

------
coldtea
rg for the win. It's not some huge improvement, but it's more of a feeling
that things just work by default (similar to what I get from tmux vs screen).

~~~
mhd
I've got the reverse feeling recently, as ag does smartcase searching by
default and rg doesn't...

~~~
nolemurs
`alias rg='rg -S'` in your `.bashrc` will fix that for you.

Out of curiosity, what sort of searches do you do that smartcase is desirable?
A meaningful number of people seem to prefer it, but I find that most of the
time I _want_ to be able to search for variables etc. case sensitively.

~~~
mhd
We were talking about defaults and feelings here, I'm aware that it's easy
enough to fix (and to be fair, I now often use ripgrep with the inverse
alias)…

I'm generally a big fan of smartcase. Most of the time I don't care about case
and it's easier to type it that way, and when I care, it's often mixed or
upper case, so smartcase Does What I Mean. And for the few times when I
explicitly search for all-lowercase, it's easy enough to turn it off (M-c, -s,
:set nosmartcase etc.).

------
petre
Ack and ag use Perl/PCRE so they're more useful than grep/rg if you know Perl
style regular expressions.

~~~
avar
GNU grep supports PCRE as well.

------
dh-g
switched from ag to rg a few months ago and have nothing but good things to
say about the experience.

~~~
jedisct1
Same here.

Ripgrep works like a charm

Ack requires Perl, which I am not going to install just for that purpose.

~~~
petdance
What kind of OS are you running that Perl isn't installed already?

~~~
rektide
An ideal one.

Like, platonic ideal- because it doesn't exist. That greatly ideal.

I don't know why I care, other than even the super cut down perl being a
sizable % of the install size for some of the very small systems I've worked
with.

------
visarga
Any modern tools like this?

sary - a suffix array library and tools
[http://sary.sourceforge.net/](http://sary.sourceforge.net/)

It finds words in O(log(n)) time by using an additional index.

~~~
burntsushi
The problem with suffix arrays---even with a blazing fast SACA---is that they
are slow. It will take a long time to generate an index for even a moderately
sized code repository.

Typically, if you want an index, you build an inverted index, which maps terms
(e.g., n-grams or tokens in your favorite PL) to a postings list. The postings
list contains all of the documents in which that term occurs.

------
masklinn
> No descending into subdirectories

> Limit directory search depth

These could be the same item, the former is a special case of the latter.

------
akerro
The table somehow missed MIT grep.

------
caio1982
What has always amazed me is how super fast ack is in my use cases.

------
hashkb
I've been using pt for a few years... am I dumb or do I have a secret?

~~~
burntsushi
Neither. pt is part of the benchmark suite I published when I introduced
ripgrep[1]. TL;DR - It's fast for simple literal searches, but that's it.

[1] -
[http://blog.burntsushi.net/ripgrep/](http://blog.burntsushi.net/ripgrep/)

------
iameli
Missing `git grep --name-only`

~~~
petdance
There's a link to the issue tracker right there at the top of the page.

