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

91–98 of 98 posts

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

#91

Post by undebuggable »

bberrry wrote: post #27
undebuggable wrote: post #19

Earlier quoted context omitted.

> ripgrep Whait what's that? I'm stuck with ag and {a..z}grep.

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 grep GB+ sized files, you'll love it.

TBH more frequently I have "argument list too long" problem, than "one 5GB file" problem.

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

#92

Post by gugod »

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.

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.

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

#93

Post by kristopolous »

benj111 wrote: post #68
lloeki wrote: post #15

Earlier quoted context omitted.

> raku is perl 6 It used to be, but not anymore. It has grown to be its own thing with some happenstance parenthood through being born from an early attempt at Perl 6, and thus is now only being slightly more related to Perl than e.g Ruby is. Ok I'm pushing it but you get the idea: taking a biological analogy, it has mutated away far enough that it is now considered to be its own strain. And if that helps clear some…

I don't think the mutation analogy really works. C of 40 years ago is nothing like modern c. Same for basic.

I just found out recently that many k&r c'isms are actually obsoleted as in will break the compiler.

    int foo(s, f)
     char* s;
     float f;
    { ... }
That notably is now broken as per C 2X

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

#94

Post by lizmat »

burntsushi wrote: post #58
throwawaaarrgh wrote: post #56

Earlier quoted context omitted.

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 t…

FWIW, on some MacBook Pro keyboards, the § is right next to 1:

https://keyshorts.com/blogs/blog/37615873-how-to-identify-ma...

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

#95

Post by lizmat »

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…

$ 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: .all}'

Or using whatever currying: https://docs.raku.org/type/Whatever

$ rak '*.contains: .all'

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

#96

Post by lizmat »

pie_flavor wrote: post #78

Since the rest of the comments are about the language, I guess mine may as well be too. I was wondering why, in your coding style, you always use $y.ACCEPTS($x) instead of $x ~~ $y?

I assume this is directed at the author of rak, so I'll answer.

$x ~~ $y is basically syntactic sugar for $y.ACCEPTS($x). Using ~~ involves an additional subroutine call, so there's a short-term efficiency issue (as in programs running more than a second or so the extra call will have been inlined).

But personally, I like the verbosity of $y.ACCEPTS($x) as it reads better for me, having been burnt by ~~ semantics in Perl, which was symmetrical.

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

#97

Post by melezhik »

fastball wrote: post #2

This is my first time hearing about Raku (the language this tool is apparently written in), and after a quick look at the website[1], I am not sure why I would want to use Raku vs any other language in particular. According to the guide[2]: > Raku is a high-level, general-purpose, gradually typed language. Raku is multi-paradigmatic. It supports Procedural, Object Oriented, and Functional programming. That really doe…

Because it provides one with a lot of flexibility out of the box while not forcing you into a specific programming style and without any additional overhead or costs …

OOP, functional programming, strong/dynamic typing, declarative /imperative - you’ve got it, we got you covered

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

#98

Post by melezhik »

PhilipRoman wrote: post #6
fastball wrote: post #2

This is my first time hearing about Raku (the language this tool is apparently written in), and after a quick look at the website[1], I am not sure why I would want to use Raku vs any other language in particular. According to the guide[2]: > Raku is a high-level, general-purpose, gradually typed language. Raku is multi-paradigmatic. It supports Procedural, Object Oriented, and Functional programming. That really doe…

Raku is a Perl descendant so it's goals are the same as Perl's (for the most part). From what I've seen it is supposed to be a terse language for rapid prototyping, it has syntax support for a lot of common idioms (and of course since it came from Perl you can expect some of the best pattern matching support in the world). For me the performance is a dealbreaker, but otherwise it looks pretty good.

The are lot of tasks that don’t require performance, so if you are not going to write embedded / real-time system - you should be fine
Post reply on HN