Has it caught up to ugrep in terms of backward compatibility and speed yet?
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