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

61–70 of 98 posts

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

#61

Post by cedws »

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.

This is why I'm also skeptical of the "modern" replacements, like Just for example. The majority of developers already have Make on their system and Make works well enough. When you use Just instead, you're adding friction to the build process for some portion of people who want to work on your code. You have to context switch to go and install it. Brew decides it wants to upgrade everything. Aaaand you've wasted 15 minutes because you went to get a coffee in the meantime.

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

#62

Post by IshKebab »

mkl wrote: post #21
erezsh wrote: post #5

It's not clear from the README what advantages it offers over ripgrep.

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 '/ > /' 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("fo…

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.

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

#63

Post by _v7gu »

larodi wrote: post #55

definitely not going to install cursed Raku for this single search lib. perhaps if they had a distributed binary in some byte-code format, but they don't. because forked-Perl-guys were busy figuring how to use all the Unicode and outpace APL in complexity, while others were figuring how to target reasonably large distribution medium (think wasm, .net, and jre if u want). besides, ripgrep IS much more state of the art…

APL is one of the least complex languages I know (simplest being Lisp); there isn’t much syntax to learn and the language doesn’t really have implicit footguns. You just string together function applications and modify some of those functions with adverbs

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

#64

Post by hiAndrewQuinn »

zgk7iqea wrote: post #54
hiAndrewQuinn wrote: post #23

Earlier quoted context omitted.

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

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.

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

#65

Post by pizzalife »

burntsushi wrote: post #44

Author of ripgrep here. Very cool! It looks like Rak has a lot of nice features. I will say that getting this thing built took some digging. Could you please add install/build instructions to the README? As it is, I had to go sleuthing through your CI setup to figure it out. On Archlinux, here's what I did: $ yay -S rakudo-bin $ export PATH="/usr/share/perl6/site/bin:$PATH" $ git clone https://github.com/lizmat/App-R…

Just wanted to say thanks for rg! I use it every day.

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

#66

Post by pizzalife »

nsrahmad wrote: post #7
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…

I really like this post about Raku: "Raku : A Language for Gremlins" https://buttondown.email/hillelwayne/archive/raku-a-language...

Wow, that looks absolutely horrible.

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

#67

Post by lizmat »

burntsushi wrote: post #44

Author of ripgrep here. Very cool! It looks like Rak has a lot of nice features. I will say that getting this thing built took some digging. Could you please add install/build instructions to the README? As it is, I had to go sleuthing through your CI setup to figure it out. On Archlinux, here's what I did: $ yay -S rakudo-bin $ export PATH="/usr/share/perl6/site/bin:$PATH" $ git clone https://github.com/lizmat/App-R…

Author of App::Rak here:

> I'm not totally clear on what kind of filtering `rak` does by default

By default, rak search all of the files that look like text, by reading the first 2K (if I remember correctly) and using some algorithm to determine "binaryness".

> I realize features and an expressive language is your main goal

Indeed.

> I wanted to see what it looked like from a perf perspective

The performance times you've given here, coincide with my findings. Which for the "sixteenth.txt" surprises me: a bare loop in Raku reading that file line-by-line finishes in 8 seconds for me. Which would be one order of magnitude less than the search result. Still not in `rg`'s ball park, but speed wasn't a big concern for me. But 8 -> 48 seconds is a pretty big difference, so I guess it's back to the drawing board for me on that one :-)

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

#68

Post by benj111 »

lloeki wrote: post #15
kristopolous wrote: post #9

Earlier quoted context omitted.

raku is perl 6, it's just called "raku" now. Given that, it's 23 years old and done by Larry Wall so it's not exactly yet another fly-by-night hype language, just something that is not in the top 50.

> 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.

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

#69

Post by librasteve »

larodi wrote: post #55

definitely not going to install cursed Raku for this single search lib. perhaps if they had a distributed binary in some byte-code format, but they don't. because forked-Perl-guys were busy figuring how to use all the Unicode and outpace APL in complexity, while others were figuring how to target reasonably large distribution medium (think wasm, .net, and jre if u want). besides, ripgrep IS much more state of the art…

installing raku via rakubrew.org is quite painless tbh, it comes with zef, the standard raku package manager and then just ```zef install App::Rak```

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

#70

Post by mkl »

IshKebab wrote: post #62
mkl wrote: post #21

Earlier quoted context omitted.

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 '/ > /' 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("fo…

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 efficient rak way to do that chain of .contains? Why not demonstrate that?
Post reply on HN