It's phenomenal, is what it is. An extremely fast, recursive-by-default, general-purpose `grep` clone in Rust.
Alongside `fzf` and `fd` (a similar project for `find`) `rg` was what finally convinced me to put together a few shell scripts to bootstrap getting all my favorite modern command line tools on a new Ubuntu VM [1]. I'm working on an interactive playground you'll be able to SSH into to try it out yourself without even having to spin up your own, so you can see the difference with your own two eyes, no VM required.
Actually I'm running NixOS on an old ThinkPad I have lying around here. Home Manager works great! But Ubuntu currently has the popularity network effect going for it, so.
To me, the two big things about ripgrep are (1) it's much more oriented towards the use case of searching a directory hierarchy full of code, eg by default it's recursive and respects .gitignore, it has a --type flag which knows various kinds of source files (eg --type c will only look at .c and .h files), etc, and (2) it's fast - uses all the lastest and greatest algorithms, and makes heavy use of parallelism. It's also just generally good and sensible.
At my previous job I often ended up searching raw log files sized around 5-8GB. Regular grep would grind away for 50-60 seconds, while ripgrep returned the same results in 250ms.
I was shocked the first time I used it and have sung it's praises since.
If you can afford it (these products tend to be expensive if they're doing it, and resource hungry if you're doing it, and sometimes both) and you've got logs in files, look at having the logs live in dedicated software.
I have used (at different places) Graylog and Splunk, New Relic is also popular.
Not that ripgrep isn't awesome, but you could have dedicated indexing and a UI that can be shown to non-technical or at least semi-technical people to review logs whereas "Just use ripgrep" really isn't accessible for most users.
Yeah we had ELK for the common logs. This file was a special case that we didn't want indexed and widely accessible because it contained sensitive data. I only occasionally needed to do some digging, so I was fine resorting to ripgrep.
BurntSushi (dev) built a grep replacement, `rg` (ripgrep), in Rust, that tends to run circles in terms of speed around grep itself and other grep replacements. The UX is also pretty nice. I install it everywhere now.
I'm curious (like others here) how `rak` is better than `rg`.
It is "better" in the sense that it uses Raku regexes, which are incredibly powerful, and if that's not enough for you, you can even write code. "rak" is giving you a general-purpose programming language (Raku) that is optimized for text processing, with convenient shortcuts for the most common tasks.
In contrast "rg" only designed to search text files, but it does that really really fast.
It definitely makes sense to have this tool if you're comfortable writing Raku. I'm not sure it makes a whole lot of sense for most people to learn Raku to use this tool, and if you're not going to learn Raku I don't think there's much value add over tools like ripgrep.
Both learning and the ability of tools are gradual though. For doing naive substring search all grep-alike tools works perfectly, and anyone who are willing to spend some effort and learn a bit of tool-specific features can gain a lot more more benefits.
rak is backed by the entirety of raku language and therefore is much easier for some crafting something that's less trivial to generalize in a one-liner. For most of grep-alike tools, their regex engine would be some sort of ceilings of what can be done but for rak, the ceiling is as tall as the raku programming language. That's rak's niche.
in a strange way I both agree and disagree with this:
+ I use raku a lot so it is very natural to embed raku code in a Rak CLI
- I think that there a several benefits of the Rak tool that vanilla grep (or ripgrep) does not offer (eg. embedding code snippets in the expression, unicode, better regex syntax) that would probably make it worthwhile to learn the Rak examples while not having to bother with wider raku
- Support for NFG (Normalization Form Grapheme), which e.g. means that you only need to specify 'é' if you want to look for an 'é', and not have to worry about whether the text you're searching in, consists of the single codepoint 'é', or that it has the decomposed version.
- support for --ignoremark, which means you 'e' will match any accented 'e', such as éëêèęėē.
Ah yeah that's a good one! It does very likely have enormous implications for performance though. I wonder if I should add it as an opt-in feature to ripgrep. Although its support will be inherently limited in some capacity since character classes will always be limited to matching a single codepoint. (i.e., No UTS#18 Level 2 support.)
Have you found folks using these particular Unicode features in practice? I don't think anyone has request it for ripgrep.
> It does very likely have enormous implications for performance though.
Well, but that's only one of the reasons why rak is a lot slower. There's something else going on, but I currently don't have the mindset to investigate this deeply.
Whait what's that? I'm stuck with ag and {a..z}grep.