Anyway I'm trying to retrain the fingers these days, rg is super cool.
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.
For other people, on Ubuntu install the `fd-find` package. The executable is named `fdfind` (no dash).
I had a similar thing with bash vs zsh before I learned about oh-my-zsh. Nushell also seems attractive these days... the good stuff from PowerShell in a POSIX-like shell.
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
$ (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
$ time ag '^\w{42}$' full.txt
ERR: Skipping full.txt: pcre_exec() can't handle files larger than 2147483647 bytes.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
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.
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.
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/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.
I also find that combining `-o/--only-matching` and `-r/--replace` has replaced many of my uses of `sed` and `awk`.