The README seems to make it clear that increased finger exercise is an advantage (steroids are used for increasing muscle mass, after all).
Instead of just typing
rg '\bfoo\b'
you get to type
rak '/ << foo >> /'
and instead of just typing
rg -B2 -A2 foo
or
rg -C2 foo
you get to type
rak foo --before=2 --after=2
(over double the characters!) and instead of just typing
rg 'foo.*bar|bar.*foo'
you get to type
rak '{.contains("foo") && .contains("bar")}'
which has double the characters and also has the advantage of writing each pattern only once.
Okay, I haven't actually tried it (and the README doesn't say how to), and rak does have a bunch of features and capabilities ripgrep doesn't have, but those first examples are not very inspiring after the big initial claim.
[Edited to add] Also, the `\b...\b` form is shorter with rak - as the README also states where it documents this pattern form:
> §string
> If the pattern starts with §, then it indicates that the string should occur as a word (with word-boundaris on both ends) in the item. Basically a shortcut to specifying string --type=words. Any --smartcase, --smartmark, --ignorecase or --ignoremark arguments will be honoured.
That's not correct. ASCII has only 128 codepoints and its maximum value is 127 or 0x7F. Code 167 is not part of ASCII. You're probably thinking of ISO 8859-1.
U+00A7 (codepoint 167) is also the Unicode codepoint for §. Its use on this very web page is via Unicode and the UTF-8 encoding as the bytes \xC2\xA7.
(This is meant as a narrow correction. It doesn't really change the broader point that § is not exactly easy to type on most keyboards. Whether its ASCII or not.)
Sorry, you're right. I guess I meant 8859-1 as opposed to Windows codepages or Unicode-exclusive. My Western bias is showing as I don't know if there are old locales that wouldn't have it that would affect any international users, but I assume not?
rak '{.contains("foo1") && .contains("foo2") && .contains("foo3") && .contains("foo4") && .contains("foo5")}'
My point is that despite their claim of superiority, their examples do not show any. Maybe there's a more efficient rak way to do that chain of .contains? Why not demonstrate that?
It's not clear from the README how even to install it, likely just an exploration of writing file searcher in Raku and not a serious attempt at replacing grep/find/ack/ag/rg.
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.
The README seems to make it clear that increased finger exercise is an advantage (steroids are used for increasing muscle mass, after all).
Instead of just typing
you get to type and instead of just typing or you get to type (over double the characters!) and instead of just typing you get to type which has double the characters and also has the advantage of writing each pattern only once.Okay, I haven't actually tried it (and the README doesn't say how to), and rak does have a bunch of features and capabilities ripgrep doesn't have, but those first examples are not very inspiring after the big initial claim.
The examples are all undeniably verbose, but the source shows that many short options are also supported, specifically to copy those you would expect if migrating from the alternatives: https://github.com/lizmat/App-Rak/blob/main/lib/App/Rak.raku...
So
will do what you expect.[Edited to add] Also, the `\b...\b` form is shorter with rak - as the README also states where it documents this pattern form:
> §string
> If the pattern starts with §, then it indicates that the string should occur as a word (with word-boundaris on both ends) in the item. Basically a shortcut to specifying string --type=words. Any --smartcase, --smartmark, --ignorecase or --ignoremark arguments will be honoured.
Yes, I'm mainly complaining at the choice of examples, which don't seem to back up the claim of being "rg on steroids" at all.
Typing § is not very easy on most keyboards, and is actually impossible on some keyboard-OS combinations (including mine): https://en.wikipedia.org/wiki/Section_sign#Keyboard_entry
Some diversity doesn't hurt, though. On my keyboard, it's actually easier to type than the backslash for starters.
> §string
> If the pattern starts with §,
Is it April 1st already?!
Raku embraces Unicode in a big way, and probably influenced this decision.
I wonder if keyboards in the future will settle on a way to provide access to more characters, than is currently common.
Fwiw, § is ASCII code 167, the "Section symbol". Long been used as a record separator and section marker.
I agree the keyboard thing is really annoying. Maybe the West should investigate the efforts China has put into different typing systems.
That's not correct. ASCII has only 128 codepoints and its maximum value is 127 or 0x7F. Code 167 is not part of ASCII. You're probably thinking of ISO 8859-1.
U+00A7 (codepoint 167) is also the Unicode codepoint for §. Its use on this very web page is via Unicode and the UTF-8 encoding as the bytes \xC2\xA7.
(This is meant as a narrow correction. It doesn't really change the broader point that § is not exactly easy to type on most keyboards. Whether its ASCII or not.)
Sorry, you're right. I guess I meant 8859-1 as opposed to Windows codepages or Unicode-exclusive. My Western bias is showing as I don't know if there are old locales that wouldn't have it that would affect any international users, but I assume not?
FWIW, on some MacBook Pro keyboards, the § is right next to 1:
https://keyshorts.com/blogs/blog/37615873-how-to-identify-ma...
Perhaps for further emphasis:
Yep, edited that in as you were commenting.
Come on, you can make an equally sarcastic argument about how difficult to remember and error prone regexes/short options are.
Do the "contains" example with 5 terms.
> Do the "contains" example with 5 terms.
or, if filename matches are a possibility vs My point is that despite their claim of superiority, their examples do not show any. Maybe there's a more efficient rak way to do that chain of .contains? Why not demonstrate that?$ rak '{.contains: "foo1" & "foo2" & "foo3" & "foo4" &"foo5"}'
This actually shows one of the secret powers of the Raku Programming Language: Junctions https://docs.raku.org/type/Junction
Alternately one could express this as:
$ rak '{.contains: <foo1 foo2 foo3 foo4 foo5>.all}'
Or using whatever currying: https://docs.raku.org/type/Whatever
$ rak '*.contains: <foo1 foo2 foo3 foo4 foo5>.all'
I haven't tried this in Rak proper, but based on my understanding of the README you can do something like the following:
That's a bit though; it'll match lines that contain exactly one of "foo1", "foo2", "foo3", but not zero or 2+.It's not clear from the README how even to install it, likely just an exploration of writing file searcher in Raku and not a serious attempt at replacing grep/find/ack/ag/rg.
It was introduced at a Raku Conf presentation. I remember watching it.
https://conf.raku.org/talk/174
https://dev.to/lizmat/its-time-to-rak-part-1-30ji
> ripgrep
Whait what's that? I'm stuck with ag and {a..z}grep.
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.
[1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
At that point, why not use Home-Manager (nix pm) to configure your shell? Should be easier to manage
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.
If you grep GB+ sized files, you'll love it.
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.
> If you grep GB+ sized files, you'll love it.
TBH more frequently I have "argument list too long" problem, than "one 5GB file" problem.
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`.
https://github.com/BurntSushi/ripgrep
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.
I makes sense to have both.
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
What Unicode support does Rak (or Raku) have that ripgrep does not?
- 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.
ripgrep is blazing fast grep
While ripgrep is also 21st century, it's not on steroids. /s
I would go as far as to say that steroids are not a good idea most of the time anyway. :)
Depends on what you use them for. I squirt them up my nose to deal with dust allergies. Steroids work great!
(...I am somewhat disappointed that I don't have a ridiculously buff nose by now but at least it matches the rest of my body).
> /s
Thanks, I wouldn't have been able to tell otherwise.