Fewer bugs?

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.

What I like about both is their defaults without any parameters are what i would need them for 99% of the time. Huge time saver.

rg <string>

fd <string>

I just found out the authors of both ripgrep and fd work for Astral, no wonder Astral makes such great software

This blog post is also great reading.

https://burntsushi.net/ripgrep/

Backcompat with what? ripgrep was, is and will never be POSIX compatible: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#can...

Aa for ugrep, flipping the question around would be more appropriate. ugrep has caught up with ripgrep in some common cases, but not all.

To back up what I said earlier, a common case for ripgrep is to search a code repository while respecting gitignore, ignoring hidden files and ignoring binary files. Indeed, this is ripgrep's default mode.

For example, in my checkout of the Chromium repository, notice how much faster ripgrep is at this specific use case (with the right flags given to `ugrep` to make it ignore the same files):

    $ hyperfine --output pipe 'rg Openbox' 'ugrep-7.5.0 -rI --ignore-files Openbox ./'
    Benchmark 1: rg Openbox
      Time (mean ± σ):     281.0 ms ±   3.6 ms    [User: 1294.8 ms, System: 1977.6 ms]
      Range (min … max):   275.9 ms … 286.8 ms    10 runs

    Benchmark 2: ugrep-7.5.0 -rI --ignore-files Openbox ./
      Time (mean ± σ):      4.250 s ±  0.008 s    [User: 4.683 s, System: 2.154 s]
      Range (min … max):    4.242 s …  4.267 s    10 runs

    Summary
      rg Openbox ran
       15.12 ± 0.19 times faster than ugrep-7.5.0 -rI --ignore-files Openbox ./

    $ hyperfine --output pipe 'rg -u Openbox' 'ugrep-7.5.0 -rI Openbox ./'
    Benchmark 1: rg -u Openbox
      Time (mean ± σ):     233.9 ms ±   3.3 ms    [User: 650.4 ms, System: 2081.6 ms]
      Range (min … max):   228.8 ms … 239.8 ms    12 runs

    Benchmark 2: ugrep-7.5.0 -rI Openbox ./
      Time (mean ± σ):     605.4 ms ±   6.4 ms    [User: 1104.1 ms, System: 2710.8 ms]
      Range (min … max):   596.1 ms … 613.9 ms    10 runs

    Summary
      rg -u Openbox ran
        2.59 ± 0.05 times faster than ugrep-7.5.0 -rI Openbox ./

Now ugrep is perhaps intended to be more like a POSIX grep than ripgrep is. So you could question whether this is a fair comparison. But if you're going to bring up "ripgrep catching up to ugrep," then it's fair game, IMO, to compare ripgrep's default mode of operation with ugrep using the necessary flags to match that mode.

Repository info:

    $ git remote -v
    origin  git@github.com:nwjs/chromium.src (fetch)
    origin  git@github.com:nwjs/chromium.src (push)
    $ git rev-parse HEAD
    1e57811fe4583ac92d2f277837718486fbb98252

This seems like an unhelpful comment?

First of all, the ugrep performance comparisons are online (and haven't been updated to compare against this version that was only released 3 days ago). So your question is answerable:

https://github.com/Genivia/ugrep-benchmarks

The two are very close and both are head and shoulders faster than most other options.

And backwards compatibility is a mixed thing, not a mandatory goal. It's admirable that ugrep is trying to be a better drop-in replacement. It's also cool that ripgrep is trying to rethink the interface for improving usability.

(I like ripgrep in part because it has different defaults than grep that work very well for my use cases, which is primarily searching through codebases. The lack of backwards compatibility goes both ways. Will we see a posix ripgrep? Probably not. Is ripgrep a super useful and user-friendly tool? Definitely.)

I'm so happy ripgrep has a different interface to grep. I don't typically need ripgrep's better performance, I just use it because 'rg foo' does what I want 99% of the time while 'grep foo' does what I want 1% of the time.

This might help: https://news.ycombinator.com/item?id=45629497

That is, you can whitelist specific hidden files/directories.

There is no way to tell ripgrep to "search precisely the set of tracked files in git." ripgrep doesn't read git repository state. It just looks at gitignore files and automatically ignores all hidden and binary files. So it make it work more like git, you might consider whitelisting the hidden files you want to search. To make it work exactly like git, you need to do the `git ls-files -z | xargs -0 rg ...` dance.

It’s better than the normal grep, and there’s also the handy rg —-files.

I don't think they claim they are using semver. Lots of companies/projects use "major" releases just for the added hype.

Bugfixes can be breaking changes

The most important part of semver is that breaking changes are indicated by incrementing the major version. semver does not say that the major version must only be incremented when a breaking change is present.

Semver advocates hijacked the very common and pre-existing format of versions specified by dot-separated numbers, and then declared a specific meaning for it.

That’s nice for people who want to use that specific meaning, but it doesn’t mean that every instance of dot-separated version numbers is “semver”, nor that everyone who chooses not to follow these rules is “doing semver wrong”.

People write scripts that call ripgrep. That makes the arguments an API.

Semver is useful to indicate breaking API changes.

Not sure if they are following semver, but that is the argument for using semver in a cli tool.

genuinely curious what smithing means in this context!

Have you seen the `-t/--type` flag? Your example could be written `-tc`. And for common ones that aren't in ripgrep already, you can define your own types.

[flagged]

> My only complaint is there are a couple of characters that the -F (treat as literal) option seems to still treat as a special character needing some kind of escape - though I don't remember which ones now.

If you have an example, I can try to explain for that specific case. But `-F/--fixed-strings` will 100% turn off any regex features in the pattern and instead will be treated as a simple literal. Where you might still need escaping is if your shell requires it.

What do you mean? You could pass an empty pattern. But that will match everything.

Maybe talk about your use case at a higher level.

After writing this comment, I read the man page again and found the -. flag which can be used instead of -uu.

Searching in hidden files tracked by git would be great but the overhead of querying git to list all tracked files is probably significant even in Rust.

Is this faster than `git grep`?

Can you provide a concrete example where that's faster? ripgrep should generally already be approximating `git ls-files` by respecting gitignore.

Also, `-uu` tells ripgrep to not respect gitignore and to search hidden files. But ripgrep will still skip binary files. You need `-uuu` to also ignore binary files.

I tried playing with your `rgg` function. First problem occurred when I tried it on a checkout the Linux kernel:

    $ rgg APM_RESUME
    bash: /home/andrew/rust/ripgrep/target/release/rg: Argument list too long

    $ git ls-files -z | time xargs -0 rg APM_RESUME
    arch/x86/kernel/apm_32.c
    473:    { APM_RESUME_DISABLED,  "Resume timer disabled" },
    include/uapi/linux/apm_bios.h
    89:#define APM_RESUME_DISABLED  0x0d

    real    0.638
    user    0.741
    sys     1.441
    maxmem  29 MB
    faults  0

    $ time rg APM_RESUME
    arch/x86/kernel/apm_32.c
    473:    { APM_RESUME_DISABLED,  "Resume timer disabled" },

    include/uapi/linux/apm_bios.h
    89:#define APM_RESUME_DISABLED  0x0d

    real    0.097
    user    0.399
    sys     0.588
    maxmem  29 MB
    faults  0

Maybe I’m missing something, but doesn’t ripgrep ignore untracked files in git by default already?

Through I use rg to initiate searches, my muscle memory keeps using grep after pipes.

I switched to `ack` in 2017 because it handles recursive searches better.

I didn't bother switching to `ag` when it came around because of having to retrain.

But eventually I did switch to `rg` because it just has so many conveniences.

I even switched to `fd` recently instead of `find` because it's easier and less typing for common use-cases.

I've been using the terminal since 1997, so I'm happy I can still learn new things and use improved commands.