You’ve saved me tens if not hundreds of hours with ripgrep, and I’ve become a huge evangelist of it at my workplace. When I’m helping someone understand how to debug customer issues, the first thing I tell them is to install ripgrep. Truly a fantastic piece of software.
Any time! Yeah jq is great, but my usecase is covered better by these two together.
Truly the Unix philosophy at it's finest. It's the only way I search JSON these days! (or YAML with "yq | gron | rg" to get results, pop into (n)vim and to my thing :)
Sorry, how does ripgrep save you tens of hours? I get that it is faster than regular grep, but that doesn't really answer the question; I don't find myself stalled waiting for grep. The only reasonable explanation would be something ripgrep does that grep actually doesn't. I could try to guess, but have no confidence I would guess right.
1. Available on Windows without WSL, possibly the biggest time saver for those affected
2. Auto ignores .gitignore files, so does not search node_modules or build/ etc., huge noise reduction there.
3. -t/-T gates on file extension which is a very nice feature, again signal to noise
4. The combo of speed and the above and the recursive-by-default mean that you search much larger corpuses by default, like “all the microservices in the cluster” or “my entire home dir”, because you know it's some .xml file mentioning “jackson” where you saw this config you need before.
5. For some reason I never remember which regex features are grep vs egrep, so I end up just testing on a bunch of strings to see if I have to like backslash the plus operator or whatever. With rg it's like “oh this is going to have the same syntax as JS regex.”
6. Unicode compatibility by default could save you that sort of time maybe on specific workloads?
Totally anecdotal, but I have found ripgrep orders of magnitude faster than grep when searching a large corpus of data (in my case, many multi-hundred megabyte to gigabyte XML files). As in, ripgrep completed the search in seconds, grep took multiple minutes. I'm sure I could have done some research to optimise/parallelise grep, but ripgrep worked doing the "dumb" search.
I use ripgrep on git bash for Windows, and my team members act like I’ve got searching superpowers. Searching on windows is such a pain and this makes it easy. Thanks so much for making this fantastic tool!
I use ripgrep and "everything" all the time on windows to find files and where I put stuff :) . My filing system leaves something to be desired, as does my many idea test folders.
`ripgrep` is my favorite of the "new" linux utilities, it makes searching for a single string across all of my cloned repos extremely easy, and especially for diving into multiple versions of vendored dependencies.
`ripgrep` is my favorite of the "new" linux utilities
Yeah, but only when used together with fzf, the other favorite new cross-platform shell utility. I mean, after rg spits out a list you do want to narrow it down and then do something with the files in that list, right?
You should not have done this unless you want to further normalize the practice of namespace squatting. This is the same type of behavior leads to domain squatting. While arguably being slightly more benign in the sense of hedging against typosquatting, if everyone started going things like that, we'd quickly begin to run into namespace exhaustion problems as people started ballooning their package namespace footprint.
Before you do something like that, always ask yourself: "What if everyone else started doing this?"
If the result feels like a nightmare in the making, don't do it.
> Before you do something like that, always ask yourself: "What if everyone else started doing this?"
No, I don't think so. There is no universality implied in my comment or in the specific practice here. You can make value judgments based on specific circumstances. For example:
* How many people try 'cargo install rg' and have it do the wrong thing? I'd say "probably a lot."
* Is 'rg' on its own something that is a likely useful or desirable name on its own? No, I don't think so.
This doesn't have to mean that everyone should do it for every possible alias of every crate out there. You can say things like "yeah I think it makes sense to squat a name here to improve failure modes for folks."
Other than that, I have squatted a few names before. I don't see anything wrong with the practice in and of itself. It's when it gets abused that it starts to become a problem.
I've worked on various package management ecosystems for close to a decade now, and I wouldn't qualify this (if 'burntsushi had done it) as namespace squatting. It's clearly not an attempt to reserve a name for unspecified future use (or as a potential typosquatting target); it's the name of the binary installed by the crate and an obvious mistake for an installing user to make.
Even flat namespaces are virtually infinite; a couple of extra names that correct user error do not pose a serious exhaustion risk.
I'd like to note there are three perverse incentives that lead to abuses of public namespaces (that I am aware of - please tell me if I've missed any):
1.) The use of names as a speculative financial instrument (in all shades of grey, up to and including extortion for lapsed or stolen names)
2.) The use of names as vectors of attack, such as by exploiting typos or homographs (such as malicious packages)
3.) The reserving of names you don't have a sincere or immediate intention to use (hoarding/FOMO)
This isn't very much like the situation with domains, which is primarily a result of #1 (there is no market for crates.io names, as far as I'm aware). #3 is a problem to some degree on crates.io, my understanding is that they basically treat this as a human moderation problem. #2 is endemic to all package managers.
By putting a helpful instead of malicious package here, the community (and Richard Dodd in particular) are able to mitigate the hazard of #2 (unless this account is compromised or turns malicious - a better but imperfect situation). If a project called `rg` comes around, they can appeal to moderators to get this name, and probably succeed (as if this were a #3 problem).
This isn't a perfect way to do things by any means, but it seems like a decent balance of concerns to me.
> #3 is a problem to some degree on crates.io, my understanding is that they basically treat this as a human moderation problem
I think it's more accurate to say that they consider dealing with this out of scope. "I want this name that has been unused since it was added as a placeholder package 7 years ago" is not something that the human moderation will help you with. The extent of human moderation on crates.io is basically "This is malicious or illegal and was reported to us and we looked and agreed so removed it"
Someone else already has 'nyt.com' ('rg'), GP is saying (not saying I agree) 'nytimes.com' ('ripgrep') behaviour encourages other someone elses to do that sort of squatting, where they don't own the thing that is clearly intended.
I'm fully in support of exhausting namespaces in programming languages. It's really annoying that people keep making one-off projects with weird names that reinvent the wheel.
In CPAN, you create a module with a hierarchical name (Net::LDAP), and people inherit from it and extend the namespace to add new functionality (Net::LDAP::Batch). Finding a package that does what you want is [relatively] easy. Old code gets maintained rather than somebody reinventing it for the 72nd time with a hodge-podge of functionality.
This classic version of this in the Ruby ecosystem is "bundle"[1], which helpfully installs `bundler` for you. Of the 6.7 million downloads it has, I'm probably in there a dozen or so times.
Hi - author of `rg` here :'). I've transferred over to BurntSushi which will give people a bit more assurance that `rg` won't become malware in the future.
I also squatted `memap` and `memap2` for the same reasons.
I wonder if there is an algorithmic way to decide when two crate names are 'near' each other. Then, if you added a crate with `cargo add` and there is another similarly-named crate with much higher usage, a warning could be emitted.
*EDIT* I know there's already https://en.wikipedia.org/wiki/Levenshtein_distance, but I wonder if there is a better measure that looks at e.g. keyboard layouts and likely typos. I'm sure there will have been research done on this.
If a package manager is starting from zero, and wants to have a privileged namespace such that a short name has a canonical value, it would make sense for those packages to be able to include a list of strings which the package should also reserve.
That way "ripgrep" could include "rg", searching cargo for "rg" brings back "ripgrep", not a second package named "rg", and an install could tell the user the correct name for any attempt to install it.
This also covers typo-squats, so there would be no need for packages like "memap".
Obviously this represents a low-effort vector for massive squatting, so maintainers would need to be responsible for preventing that, and could add some typos themselves, being the ones which see the request for the mis-typed packages.
I use fzf with an text file which lists all files installed by a package with the package name. That way if I know the header name, I can get the package name. If I know the package name, I can get all its files.
A friend of mine in college installed this on my laptop when I had my back turned. For a month or so, I wondered why anyone thought this feature was a good idea, and why no one I knew who used MacOS seemed to complain about it.
crates.io doesn't try to build crates. It couldn't do that anyway. Crates can require arbitrary C library dependencies, only run on some specific targets, etc. That's why docs.rs has to make some effort to be able to build crates, and even it doesn't get all of them.
There is some server side verification, mostly around checking that the dependencies all exist, the file isn't too large, etc. But 99% of the testing happens on the client.
Huh - the same author also has https://crates.io/crates/memap and memap2, which explicitly say that they're "squatting to prevent a malicious typo package".
Not sure how to feel about this... on an individual-package level, it seems a sensible enough idea, but if it becomes a widespread practice, the namespace could get really cluttered.
To me the problem solved by namespaces is making it clear what's an official package of a project and what's a non-malicious third party package intended to work with that project.
e.g. bevy and amethyst have claimed a load of crate names like bevy-x or amethyst_y because they thought they might release an official addon to their framework to handle those areas. e.g. bevy did it with this https://github.com/bevyengine/bevy-crate-reservations/blob/m... and amethyst did it the long way as far as I know
Organisations wanting to have consistent package names and users wanting to identify related packages are smaller problems than the "all the good names are taken" and "packages can impersonate other packages with typos" problems.
I'm not sure I necessarily agree with that... But yeah I specifically did not want to get into what namespaces do solve, and so was instead vague and just acknowledged that they're good for something. :-)
I will also say this: at the level of personal preference, and given my understanding of many other package ecosystems, I would have preferred namespaces from the start. But I don't feel very strongly one way or the other to be honest.
> "packages can impersonate other packages with typos" problems
I was pointing out that this is specifically not solved at all by namespacing. A package's name includes its namespace, and the namespace can be typo-squatted. (EDIT: Or wait, maybe I'm misunderstanding what you're saying. Perhaps I'm confused by what "these" refers to in your last sentence.)
Popular crates could be "symlinked" into a global verified namespace, problem solved? I can't see any downsides other than some extra administration perhaps.
Yes, you buried all of the very difficult parts of your suggestion in "extra administration." Who decides what's popular? Who decides when it isn't popular any more? Who decides who gets which name in the global namespace?
I think I'm just going to refrain from talking about namespaces now. I tried to be super vague and just point out one thing that wasn't solved by namespaces (typo-squatting), but I've somehow gotten sucked into this discussion.
No more. I'm done. Sorry, it isn't directed at you. Just tired of the discussion around namespaces and the neglect to account for the "admin" parts of it.
For malicious intents, yes. But, for legitimate reasons where you need to have an "rg" package with a completely different use case, owner namespaced packages might provide a uniform solution.
What does one do if they wish to see the actual contents of this crate? The web interface I'm looking at contains no hints at peeking inside, not even direct archive download links, nothing.
I can't believe that a good way to see what's inside is to make a rust project, add the crate and then go searching around the local filesystem.
No, it's worse, if you `pip install scikit-learn` you get a library importable as `import sklearn`. It's more than a usage or documentation issue, the code itself doesn't match the name on the can.
(and `pip install beautifulsoup4` lets you `import bs4`)
Back when npm didn’t have any “similar name” restrictions I did the same for some popular packages. My redirects also helped me a couple of times as I wonder whether a package name had a dash or not.
I never run cargo install or any other package manager download commands without checking the website of the package manager for the right name first, ensuring the author is right, and the commit/update history looks right.
I love Python but pip/pypi and imports always felt wierd to me because of namespaces, package names, special imports "as", etc., maybe this is a bias because I started using them when I was younger and now I'm more experienced, I already know how to use most package managers.
BTW Ripgrep is awesome, I'm learning Rust and it's an inspiration to me, thanks burntsushi!
It would be nice if crates supported being signed with GPG or minisign or whatever.
I can imagine for example, importing keys from only the authors that I think I can trust, and passing a flag to cargo that only allows using those packages for cargo install or cargo add.
In this case I think just checking the top level crates signature (and not dependencies) would be enough to mitigate a lot of issues including typo squatting.
Tools like Packj[1] that check for typosquatting and install packages under a sandbox can help in avoiding accidental installation of malicious packages. Disclaimer: I’m one of the devs.
For what it's worth: using a tool like pypi-parker technically violates PEP 541[1], since it uploads projects with no functionality solely to reserve parts of the namespace. You may or may not get away with using it, depending on how you use it, but PyPI's admins (who I do not speak for) would be within their enumerated rights to ban any account that uses it to squat names.
Thanks for flagging this, I was unaware! I agree with your assessment; I just hope that this is considered to not be in breach of the spirit of the PEP. It seems like the PEP intended to disallow squatting in terms of pre-emptively reserving and hogging names, the way domain squatters do it. So hopefully typosquatting prevention for the sake of security is considered fine by the admins; especially since our project was designated a 'critical project' and stricter security measures apply to our maintainers.
I wouldn't sign off on this personally. It makes auditing harder. You see `cargo install rg` somewhere, but you also see that `cargo install ripgrep` is what's listed in ripgrep's README. So now you wonder, is `cargo install rg` correct? Then maybe ripgrep has to add a note about this to the README, and maybe you see it, maybe you don't.
Better to just make `cargo install rg` fail so that it never worked in the first place. `cargo install ripgrep` is also more self-describing and gives you a better search engine query.
To my knowledge this is the only wrong crate I've ever installed due to my own error. It's... not a good feeling to read this message, even though the author turned out to be doing me a favour. :)
In spite of some tense conversations with the author I am still a rg super fan: it’s fantastic, reliable, performant, well-maintained software and I would recommend it to anyone. It’s best in class.
Aliases turn a flat namespace into a potentially cyclical graph, and introduce all kinds of permission considerations (Should a non-owner be able to alias a project? If so, should they be allowed to update it?).
The solutions here are non-flat namespacing (which has worse UX, since `cargo install some-tool` now becomes `cargo install whats-their-handle-again/some-tool`) or some kind of content addressing (which is similarly bad for UX, if not worse). Most package indices choose neither, and "solve" the problem by playing whac-a-mole with abuse instead.
Clojars has the right idea for namespacing: some-tool is an alias for some-tool/some-tool.
This means the first package to squat on the name can use the shorthand version, while allowing other packages with the same name in other namespaces. (which may be forks or entirely different packages)
Edit: Because I'm on a Zoom call that will never end.
"ripgrep is a line-oriented search tool that recursively searches the current directory for a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files."
A grep alternative that optimizes for performance: https://github.com/BurntSushi/ripgrep . There are detailed performance comparisons and discussions in the readme there.
It also defaults to ignoring hidden and binary files. It's also simultaneously the thing folks cite as their favorite part about ripgrep.
The idea behind it is that it acts a heuristic for reducing false positives from your search results. For example, ripgrep replaced several little grep wrapper scripts I had in ~/bin.
And fortunately the default behavior is easy to disable. `rg -uuu foo` will search the same stuff as `grep -r foo ./`, but will do it faster.
I love that ripgrep honors .gitignore, but the fact that it skips hidden files is annoying because of questionable decisions from tool makers who insist their configuration files should be hidden files. It is especially infuriating when working with GitHub and GitLab configuration directories. On the other hand I never want ripgrep to enter the .git directory.
I recently came up with this alias to make ripgrep do what I want: do not skip hidden files, except for the .git directory:
alias rg="rg --hidden --glob '!.git/'"
(Note: if you try entering this alias interactively, you may have to escape the '!'...)
Yeah that alias is a good one, here are some other avenues:
* The repo can add a `.ignore` or a `.rgignore` whitelisting things like `.github`. ripgrep will pick up that whitelist automatically and search `.github` even though it's hidden. But this relies on the repo adding ripgrep-specific config files, which is maybe not so realistic. (Or not universal enough to rely upon.) But it could work fine for repos under your control.
* Add '!.github/' to, e.g., `~/.config/ripgrep/ignore`, and then add `alias rg="--ignore-file ~/.config/ripgrep/ignore"`. That will become a global ignore file (with low precedent) that will whitelist `.github` everywhere.
I use ripgrep everywhere, not only in my own repositories, so the first approach won't work for me. The second one, on the other hand, sounds like a really good idea, going to look into it, thanks.
If I'm understanding this correctly, ripgrep parses multiple possible configuration files and is still one of the fastest tools I've ever used? That is amazing.
There is a ripgrep "config file" (not mentioned in my previous comment), but there is only one and you have to set it via RIPGREP_CONFIG_PATH.
The things mentioned above are "ignore files," which are a sort of configuration for whitelisting and blacklisting files to search in a directory tree. And yes, you can splat them down into any directory, and if ripgrep enters that directory, it will read it and respect it. (Unless you tell it not to.)
If there are a lot of files with a lot of patterns, indeed, that can wind up taking a chunk of time not only building the matchers for each config file, but for actually matching them against every path. Sometimes it takes longer than not ignoring files at all! But if your ignore files are permitting ripgrep to skip GBs of data that GNU grep wouldn't otherwise skip, well, that's going to be a huge win no matter how you slice it.
ripgrep does use multi-threading as well, and it makes sure every ignore file is parsed and built only once. All other threads can then share the one single matcher.
"decently fast" is a significant understatement. It is likely the fastest similar tool. (`git grep` may win due to not listing the directory tree and packed files and GNU grep is very fast if you don't use Unicode, but other than that ripgrep wins).
That monstrosity is easily one of the two most popular reasons cited by folks as being the reason why they use/like ripgrep. (With the other reason being performance.)
Orthogality is a means to an end, not an end itself.
because it suits the pragmatic 90% case and not some "what if" scenario. It has quite adequately outlined what files it does search and also how to overcome the defaults. If you use CLI you can use --help as well and get the other options.
It's the correct default for me. I don't want to grep heinous output files by default, like my gigabytes of generated KML files. I appreciate that rg (and ag) ignores those files by default, and 90% of the people I show it to agree.
Because you hardly ever want to grep through your build artifacts or node modules? I don’t remember any one time I had to explicitly tell ripgrep to search through all the files in a repository
Even in an insane setup you generally don't want to search both at once. I find the pattern of first grepping non-ignored files and then cd-ing into my build directory or whatever and rerunning more helpful anyway.
Do you change the name every time there is a change in the maintainers' team?
If you have `ripgrep-team/ripgrep` rather than `ripgrep`, it doesn't help at all with people typing the wrong thing, like `rg-team/rg`. I fail to see how it helps.
It's even worse with packages that are (currently) authored by a single person, how many people know the name of ripgrep's author? Or rand? Or bevy?
If someone can find a meaningful case where ag is faster than ripgrep, then I'm happy to accept a bug report. I'll do my best at that point to give an analysis of the benchmark, and if it's correct, I'll either try to fix it or say why it's hard to fix.
By "meaningful" I mean "something that is noticeable to humans." So for example, reporting a bug because ripgrep took 9ms and ag took 7ms on a tiny repo is one I would consider not meaningful. :)
(Sorry about the verbose caveats, but just trying to head off responses I've got in the past.)
long time silver searcher user here. made a switch to rg and haven't looked back. although ag is still a tool of that rare breed I really have nothing bad to say about.
Life is too short to spend time just to know what ripgrep is/does.
I mean, yes, you all look so cool and I look so dumb.
But, c'mon, is this software so complex that its description doesn't fit 42 words?
Is like having a shop with no sign and no window. Everyone is saying it's great and worth shopping. But still no sign. Ridiculuos.
What are you talking about? If you bothered to search for it and go to the shop, you'd see there is not only a sign, but a huge fucking window with several signs helpfully telling you what the shop offers and even going so far as telling you when you might not want find the shop useful.
There's even a huge sign with only 12 words pithily explaining what the shop has inside.
Seems this comment was a bit subtle for some people.
Moving to a different set of quirks is not a step forward than continuing to use the ones you know. Regexes aren't de-facto standard; grep is different to egrep to perl to python to C++ to your text editor to whatever. It's a massive pain and annoying as fudge. You're a programmer you know this. A "superior" set of quirks may be better for new regex users but it is worse for everyone else who now has to know both grep (and all the other regex quirks) and ripgrep if they're going to use it. To get this done like I always have I now need to know something new. A new user doesn't care about the obsolete.
Faster? Well I have not yet experienced an issue with the speed of grep, that's my experience. I can imagine this could be compelling for uses I don't know about.
ripgrep may well be a better grep for some users. And that is Great, really! We should all try and make things better! Hurrah!
Refusing to describe how it is different and why you might like to install something non-standard (for which there could be compelling reasons) is just silly. Hyping anything at all in that context like that looks pretty bad.
The ratio of content-free hype (omg ripgrep is fantistic!) to an actual description on this thread or in the link or seemingly anywhere I clicked is pretty bad and constitutes a signal.
It sounds like you looked everywhere except for ripgrep's README. It explains upsides and downsides. Has benchmarks (with links to more, including cases where grep takes minutes and ripgrep takes seconds). It also has a link to a FAQ addressing whether ripgrep can replace grep and explains a bit more context.
More to the point, the comment you were responding to said "yeah but with less quirks." It didn't say "no" quirks. So your comment ended up being a silly non-sequitur.
Your follow-up comment looks ever worse to be honest, and sounds like an argument for never building anything different at all.
And half your comment is whinging about hype. Really? Yeah people get excited about shit that helps them get stuff done more pleasantly and faster than before. Who would have thunk it. Some great mystery.
Your comments get a big thumbs down from me (author of ripgrep).
Readme was not linked here. I looked and didn't find it in the parent link. Feel free to abuse my competence or, you know, link it in the discussion? Actually I'll do it.
This new thing has 3 /different/ quirks to perform the same task you already know.
To use the thing with "less" quirks you need to know _more_ quirks. And that can be fine! Or you might decide it as not worthwhile. But it is more quirks you gotta learn. Pointing that out is not a non-sequitur to a discussion that starts with:
>So it's grep like i already have installed and know its quirks?
"Yes, and it's faster if you need that and its ui makes more sense to me." Is an appropriate addendum.
Less quirks means you gotta learn more. And that is just life for all of us and one of the barriers that protects incumbents that are in some sense not as good. Note my selfish comment was taking my perspective that I already have grep and I already use it and know its quirks.
From your readme:
>You need a portable and ubiquitous tool. While ripgrep works on Windows, macOS and Linux, it is not ubiquitous and it does not conform to any standard such as POSIX. The best tool for this job is good old grep.
So you see how if you have to know grep anyway, less quirks isn't a great thing in and of itself to the user. Simpler to use interface, yeah that could be compelling. Or not. Faster could be compelling. Or not. Some additional feature could be compelling.
Maybe ripgrep is amazing and the future and just dandy and I wish you the best of luck with everything you want to achieve with your version of grep.
--------
>Your follow-up comment looks ever worse to be honest, and sounds like an argument for never building anything different at all
That's basically pretty rude and difficult to reconcile with what I actually said.
>ripgrep may well be a better grep for some users. And that is Great, really! We should all try and make things better! Hurrah!
Q. What is ripgrep?
A. A faster grep where some people find the defaults in the interface more usable, with some potentially interesting additional features.
What a lot of words wasted to get to that Q & A. Please feel free to improve it while maintaining that length. Signal to noise.
Bud, this was the extent of your exchange that was apparently "too subtle" for all us dumbfucks to understand:
>>> So it's grep like i already have installed and know its quirks?
>> yeah but with less quirks and runs much faster. worth trying out
> Uses regexes = has quirks.
So you start off with a passive aggressive nose snubbing. Someone comes in and spends exactly as much time on you as you deserve, and describes ripgrep in their own words by saying it has "less quirks." And indeed, a lot of people experience that precisely because ripgrep uses heuristics to reduce false positives in search results. Many folks experience that as "less quirks." You might not and many others might not, but that ain't their problem.
Then you respond with "uses regex = has quirks," as if the parent said "ripgrep has no quirks." Well, no shit sherlock, any grep is going to have regex support and any grep is going to have the quirks that come with regexes. That doesn't mean what the parent poster said was incorrect and it certainly doesn't mean the parent poster implied ripgrep had zero quirks. Your comment was a refutation of a silly straw man.
Real subtle, I know.
> Readme was not linked here. I looked and didn't find it in the parent link. Feel free to abuse my competence or, you know, link it in the discussion? Actually I'll do it.
If this was a link to a blog post about ripgrep or a release announcement or something of that sort, yeah, absolutely, the author should have given ripgrep at least a short introduction and a link to the README. But this is just a link pointing out a typo-squatted crate meant to improve failure modes. It's a "hey here's something interesting." It isn't even interesting just because of ripgrep, it's interesting because some person cared enough to try and improve failure modes and prevent someone from installing the wrong thing. If you want to know what ripgrep is from there, it's on you to go figure it out. It isn't on your fellow HN commenters. They explained what it was in their own words and you didn't like it. And now you've spent who knows how much time here whinging about "herp derp hype and but but but signal-to-noise" when it would have taken you less than 5 seconds to Google the damn word and click on the first result.
> A faster grep where some people find the defaults in the interface more usable, with some potentially interesting additional features.
LOL. This is a terrible description. ripgrep's official description is shorter and far more useful, because it gives you an idea of what it's actually doing, instead of just vaguely talking about it:
> ripgrep recursively searches directories for a regex pattern while respecting your gitignore
Bottom line is:
* You made silly snobbish comments.
* The rest of your whinging could have been mitigated by a 5 second Google search. Yes, normally, for things like release announcements[1], I include a short blurb about what ripgrep is. But this wasn't a release announcement. You want the official answer? Then go look for it. You want the (possibly described in terms of their own experience) opinion of your HN peers? Well, that's what you got. Live with it.
> ripgrep recursively searches directories for a regex pattern while respecting your gitignore
so (i) grep with the -r flag by default and (ii) has the feature of reading your .gitignore when present which is potentially interesting. But yours is still a better answer than "searches for stuff" and the many other answers here where nodobdy was saying /why/ they liked it. The tenor of that conversation on this site was the objection and remains so.
You seem to be taking this very personally and indulging in a bit of flaming of a kind @dang doesn't care for. I don't mind though. Yet again I say good luck to you.
(I'm the author of ripgrep.)