Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

App::Rak – 21st century grep / find / ack / ag / rg on steroids

github.com

Post reply on HN
Print view View original

71–80 of 98 posts

Re: App::Rak – 21st century grep / find / ack / ag / rg on steroids

#71

Post by hwayne »

mkl wrote: post #70
IshKebab wrote: post #62

Earlier quoted context omitted.

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. rg foo1 | rg foo2 | rg foo3 | rg foo4 | rg foo5 or, if filename matches are a possibility rg foo1 | rg :.\*foo2 | rg :.\*foo3 | rg :.\*foo4 | rg :.\*foo5 vs 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 effic…

I haven't tried this in Rak proper, but based on my understanding of the README you can do something like the following:

    rak '{so one ["foo1", "foo2", "foo3"].map(-> \x{$_.contains(x)})}'
That's a bit though; it'll match lines that contain exactly one of "foo1", "foo2", "foo3", but not zero or 2+.

Re: App::Rak – 21st century grep / find / ack / ag / rg on steroids

#72

Post by kristopolous »

2colours wrote: post #37
kristopolous wrote: post #16

Earlier quoted context omitted.

Well right, "perl 6" quickly became a bad name for the project - they should have switched to something like "raku" maybe 20 years ago. Given that, nobody got the memo, so calling it "perl 6" is still a very fast way to orient people as to what it's a neighbor of.

Maybe a fast way but is it a fair or even helpful way, if you recognize that it "quickly became a bad name for the project"?

Absolutely! In the same way that saying the "Dugong Dugon" is a type of fish even though it's technically a Sirenia.

Here, "some swimming creature" is the totality of the objective, we aren't trying to do a crash course in marine zoology or trying to explain what a Sirenia is or what a fish technically means.

Saying it's perl-6 means that it's not say, lisp-like or some kind of prolog or haskell. It's a relatively swift approximation and that's the totality of the objective.

Re: App::Rak – 21st century grep / find / ack / ag / rg on steroids

#73

Post by librasteve »

tialaramex wrote: post #41
GuB-42 wrote: post #36

Earlier quoted context omitted.

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.

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

Re: App::Rak – 21st century grep / find / ack / ag / rg on steroids

#74

Post by librasteve »

kstrauser wrote: post #52
Yizahi wrote: post #42

There is problem with nice modern Linux tools - they are not available on the generic servers and embedded boxes with you will likely use, or in the image someone else has given you etc. Therefore it is pointless (sorry for the strong term) to learn them, because they simply won't be available for when they are most needed. And learning new tools is not a free process, there are costs, mental and time.

I reject that heartily. I spend 90% of my shell time on my own machine, and I want it to be comfortable. Here “at home” I use nice editors, and Fish shell, and ripgrep/fzf/etc., because they make my daily life more pleasant and productive. Some remote servers are minimal to the point that they only have Bourne shell and plain vi available, and when I’m working on them, that’s what I use. But darned if I want to handc…

and Rak too ;-)

Re: App::Rak – 21st century grep / find / ack / ag / rg on steroids

#75

Post by burntsushi »

librasteve wrote: post #73
tialaramex wrote: post #41

Earlier quoted context omitted.

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.

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?

Re: App::Rak – 21st century grep / find / ack / ag / rg on steroids

#76

Post by kstrauser »

librasteve wrote: post #74
kstrauser wrote: post #52

Earlier quoted context omitted.

I reject that heartily. I spend 90% of my shell time on my own machine, and I want it to be comfortable. Here “at home” I use nice editors, and Fish shell, and ripgrep/fzf/etc., because they make my daily life more pleasant and productive. Some remote servers are minimal to the point that they only have Bourne shell and plain vi available, and when I’m working on them, that’s what I use. But darned if I want to handc…

and Rak too ;-)

And Rak, too. :)

Re: App::Rak – 21st century grep / find / ack / ag / rg on steroids

#77

Post by lizmat »

burntsushi wrote: post #75
librasteve wrote: post #73

Earlier quoted context omitted.

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 éëêèęėē.

Re: App::Rak – 21st century grep / find / ack / ag / rg on steroids

#79

Post by burntsushi »

lizmat wrote: post #77
burntsushi wrote: post #75

Earlier quoted context omitted.

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.

Re: App::Rak – 21st century grep / find / ack / ag / rg on steroids

#80

Post by sgarland »

Yizahi wrote: post #42

There is problem with nice modern Linux tools - they are not available on the generic servers and embedded boxes with you will likely use, or in the image someone else has given you etc. Therefore it is pointless (sorry for the strong term) to learn them, because they simply won't be available for when they are most needed. And learning new tools is not a free process, there are costs, mental and time.

If you control the servers you’ll be working on, you can install the tooling you’d like. If you don’t, you can lobby for it to be installed.

Some Postgres servers I work on have massive log files, and due to DDOG indexing retention being short, sometimes it’s required to go sleuthing on the host. While LC_ALL=C speeds up grep quite a bit, it’s still an order of magnitude slower than ripgrep.

Luckily, I can add tooling to these servers if there is a valid need, and “massively speeds up searches when speed is of the essence” is very much an accepted case.

Post reply on HN