3 ms·

ripgrep is a lot faster (which you might only notice on larger haystacks), has many fewer bugs and is maintained.

ahartmetz 1y ago
ag is plenty fast (gigabytes in a fraction of a second) for me - I'd switch in a heartbeat if that wasn't so. Any bugs, hm, I guess I just haven't run into them. Thanks for the reply though! I realize who replied here ;)
- burntsushi 1y ago
  Look at ag's issue tracker. There are some very critical bugs. You might be impacted by them and not even know it. As for perf, it's not hard to witness a 10x improvement that you'll actually feel. On my checkout of the Linux kernel: $ (time rg -wi '\w+(PM_RESUME|LINK_REQ)') | wc -l real 0.114 user 0.547 sys 0.543 maxmem 29 MB faults 0 444 $ (time ag -wi '\w+(PM_RESUME|LINK_REQ)') | wc -l real 0.949 user 6.618 sys 0.805 maxmem 65 MB faults 0 444 Or even basic queries can have a pretty big difference. In my checkout of the Chromium repository: $ (time rg Openbox) | wc -l real 0.296 user 1.349 sys 1.950 maxmem 71 MB faults 0 11 $ (time ag Openbox) | wc -l real 1.528 user 1.849 sys 8.285 maxmem 29 MB faults 0 11 Or even more basic. You might search a file that is "too big" for ag: $ time ag '^\w{42}$' full.txt ERR: Skipping full.txt: pcre_exec() can't handle files larger than 2147483647 bytes.
  - EliMdoza 1y ago
    been using both for many years now, have never ran into issues or even been able to tell any difference in speed, let alone 10x what I notice unfortunatly, is that I often miss search results with rg becuase I forget I need to pass the additional -i flag. this has shaped my perception of rg - extra focus on performance, sub-optimal ux
    - burntsushi 1y ago
      Whether smart case is enabled by default (as ag does) could easily go either way. Notably,.I think having it disabled by default is a better UX. But ripgrep does have a --smart-case flag, which you can add to an alias or a ripgrep config file. It also works more consistently than ag's smart case feature, which has bugs. See my other comments about perf difference. And ag has several very critical bugs. And it's unmaintained. > or even been able to tell any difference in speed If you only search small amounts of data, then even a naive and very slow grep is likely just fine from a perf perspective.
      - sshine 1y ago
        I know this isn't the perfect place for a feature request, but I've recently found it quite annoying that ripgrep ignores .github directories because they're hidden. Maybe there are similar directories that people prefer included by default. Then again, if these results suddenly pop up and people upgrade to a major version and expect backwards compatibility, the tradeoff might not be worth it.
        burntsushi 1y ago
        > I know this isn't the perfect place for a feature request, but I've recently found it quite annoying that ripgrep ignores .github directories because they're hidden. As has been suggested elsewhere in this thread, have you considered `echo '!/.github/' > .ignore` in the root of your repository? That's what ripgrep's repo itself does: https://github.com/BurntSushi/ripgrep/blob/d47663b1b4548e4fa02d6e4b575718d0f5f5e7d6/.ignore https://github.com/BurntSushi/ripgrep/blob/d47663b1b4548e4fa... There have been some requests to whitelist certain directories by default. And it will absolutely never happen. It makes the semantics too complicated and even more surprising. Today, I can just say, "ripgrep respects gitignore, ignores hidden files and binary files." But if I started whitelisting specific things, that description would no longer be correct. I'd have to add them as exceptions when explaining ripgrep's default heuristics. Plus, whitelisting a directory is extremely easy and simple. People seem to think `.ignore` files are only for ignoring. But they're not. They also let you un-ignore things without having to touch the CLI command. > Then again, if these results suddenly pop up and people upgrade to a major version and expect backwards compatibility, the tradeoff might not be worth it. I do use semver in ripgrep. That is, if I make a breaking change, then I bump the major version. Regardless, big breaking changes that aren't exceptionally well motivated are basically off the table. semver allows breaking changes to be made, but it works best in the context of libraries. For ripgrep, that has direct end users, semver doesn't really help much. Users will just experience their scripts breaking. Or commands they used to use, now don't work any more or do something different.

ag is plenty fast (gigabytes in a fraction of a second) for me - I'd switch in a heartbeat if that wasn't so. Any bugs, hm, I guess I just haven't run into them. Thanks for the reply though! I realize who replied here ;)

burntsushi 1y ago
Look at ag's issue tracker. There are some very critical bugs. You might be impacted by them and not even know it. As for perf, it's not hard to witness a 10x improvement that you'll actually feel. On my checkout of the Linux kernel: $ (time rg -wi '\w+(PM_RESUME|LINK_REQ)') | wc -l real 0.114 user 0.547 sys 0.543 maxmem 29 MB faults 0 444 $ (time ag -wi '\w+(PM_RESUME|LINK_REQ)') | wc -l real 0.949 user 6.618 sys 0.805 maxmem 65 MB faults 0 444 Or even basic queries can have a pretty big difference. In my checkout of the Chromium repository: $ (time rg Openbox) | wc -l real 0.296 user 1.349 sys 1.950 maxmem 71 MB faults 0 11 $ (time ag Openbox) | wc -l real 1.528 user 1.849 sys 8.285 maxmem 29 MB faults 0 11 Or even more basic. You might search a file that is "too big" for ag: $ time ag '^\w{42}$' full.txt ERR: Skipping full.txt: pcre_exec() can't handle files larger than 2147483647 bytes.
- EliMdoza 1y ago
  been using both for many years now, have never ran into issues or even been able to tell any difference in speed, let alone 10x what I notice unfortunatly, is that I often miss search results with rg becuase I forget I need to pass the additional -i flag. this has shaped my perception of rg - extra focus on performance, sub-optimal ux
  - burntsushi 1y ago
    Whether smart case is enabled by default (as ag does) could easily go either way. Notably,.I think having it disabled by default is a better UX. But ripgrep does have a --smart-case flag, which you can add to an alias or a ripgrep config file. It also works more consistently than ag's smart case feature, which has bugs. See my other comments about perf difference. And ag has several very critical bugs. And it's unmaintained. > or even been able to tell any difference in speed If you only search small amounts of data, then even a naive and very slow grep is likely just fine from a perf perspective.
    - sshine 1y ago
      I know this isn't the perfect place for a feature request, but I've recently found it quite annoying that ripgrep ignores .github directories because they're hidden. Maybe there are similar directories that people prefer included by default. Then again, if these results suddenly pop up and people upgrade to a major version and expect backwards compatibility, the tradeoff might not be worth it.
      - burntsushi 1y ago
        > I know this isn't the perfect place for a feature request, but I've recently found it quite annoying that ripgrep ignores .github directories because they're hidden. As has been suggested elsewhere in this thread, have you considered `echo '!/.github/' > .ignore` in the root of your repository? That's what ripgrep's repo itself does: https://github.com/BurntSushi/ripgrep/blob/d47663b1b4548e4fa02d6e4b575718d0f5f5e7d6/.ignore https://github.com/BurntSushi/ripgrep/blob/d47663b1b4548e4fa... There have been some requests to whitelist certain directories by default. And it will absolutely never happen. It makes the semantics too complicated and even more surprising. Today, I can just say, "ripgrep respects gitignore, ignores hidden files and binary files." But if I started whitelisting specific things, that description would no longer be correct. I'd have to add them as exceptions when explaining ripgrep's default heuristics. Plus, whitelisting a directory is extremely easy and simple. People seem to think `.ignore` files are only for ignoring. But they're not. They also let you un-ignore things without having to touch the CLI command. > Then again, if these results suddenly pop up and people upgrade to a major version and expect backwards compatibility, the tradeoff might not be worth it. I do use semver in ripgrep. That is, if I make a breaking change, then I bump the major version. Regardless, big breaking changes that aren't exceptionally well motivated are basically off the table. semver allows breaking changes to be made, but it works best in the context of libraries. For ripgrep, that has direct end users, semver doesn't really help much. Users will just experience their scripts breaking. Or commands they used to use, now don't work any more or do something different.