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

Show HN: A simple, fast and user-friendly alternative to find, written in Rust

github.com

Post reply on HN
Print view View original

211–220 of 225 posts

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#211

Post by mmjaa »

derriz wrote: post #28
josteink wrote: post #4

My main usecase for find is not only finding files, but to do actions on them through -exec. Unless I’m missing something, that’s not supported with this tool.

I'm curious why you (or anyone) uses -exec? It's often painfully slower than piping through xargs and I find the syntax (the semicolon and braces and the required quoting/escaping) uncomfortable. I haven't used -exec in 20 years.

YMMV? Having used find -exec for 20+ years, I find it much more difficult to convince myself to switch to tools like this, and just simpler to use -exec. That, and the extra spawn - and potential for disaster - that putting a | into the mix can incur ..

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#212

Post by burntsushi »

petdance wrote: post #210
chrismorgan wrote: post #190

Earlier quoted context omitted.

grep came, then ack-grep, then silver-searcher and a few others, finally ripgrep. For most purposes, ripgrep (the one written in Rust) is the best of all of these tools, typically being the fastest and also the most Unicode-compliant, with the main downside being its non-deterministic ordering of output (because it searches files in parallel). The only reason for using ack these days is if you’re already invested in…

What do you mean by a "invested in a Perl workflow"? Do you mean "comfortable with Perl regexes"? Other reasons that you may want to use ack: * You want to define your own filetypes * You want to define your own output using Perl regexes * You need the portability of an uncompiled tool in a single source file that you can drop into your ~/bin when you can't install or compile anything on the box. * You don't want to…

I'd like to make a few clarifications if you don't mind!

You can define your own file types with ripgrep on the command line (albeit not in a config file, so you end up needing a wrapper script or an alias).

ripgrep has pre-compiled binaries that work out of the box on Windows, Mac and Linux.

"Rust runtime" isn't really a thing. It's like you saying you don't want to deal with a C runtime.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#213

Post by edibleEnergy »

petdance wrote: post #210
chrismorgan wrote: post #190

Earlier quoted context omitted.

grep came, then ack-grep, then silver-searcher and a few others, finally ripgrep. For most purposes, ripgrep (the one written in Rust) is the best of all of these tools, typically being the fastest and also the most Unicode-compliant, with the main downside being its non-deterministic ordering of output (because it searches files in parallel). The only reason for using ack these days is if you’re already invested in…

What do you mean by a "invested in a Perl workflow"? Do you mean "comfortable with Perl regexes"? Other reasons that you may want to use ack: * You want to define your own filetypes * You want to define your own output using Perl regexes * You need the portability of an uncompiled tool in a single source file that you can drop into your ~/bin when you can't install or compile anything on the box. * You don't want to…

Thanks for writing Ack petdance! Nowadays I typically use 'git grep' but I still use ack a good amount.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#214

Post by chrismorgan »

petdance wrote: post #210
chrismorgan wrote: post #190

Earlier quoted context omitted.

grep came, then ack-grep, then silver-searcher and a few others, finally ripgrep. For most purposes, ripgrep (the one written in Rust) is the best of all of these tools, typically being the fastest and also the most Unicode-compliant, with the main downside being its non-deterministic ordering of output (because it searches files in parallel). The only reason for using ack these days is if you’re already invested in…

What do you mean by a "invested in a Perl workflow"? Do you mean "comfortable with Perl regexes"? Other reasons that you may want to use ack: * You want to define your own filetypes * You want to define your own output using Perl regexes * You need the portability of an uncompiled tool in a single source file that you can drop into your ~/bin when you can't install or compile anything on the box. * You don't want to…

I had real trouble getting ack to work when I first started using it. On Linux I had some trouble, I can’t remember what, but on Windows it was downright hard to get it to work properly. When using a new computer once I switched to ag one time because I was unable to get ack working on Windows.

I believe that defining the output using Perl regexes was what I was referring to with “Perl magic powers”. I work at FastMail, the backend of which is mostly Perl, and have been unable to convince most people to use ripgrep because they like Perl and ack and occasionally use some of that fancy superpower. I, on the other hand, lack that experience (I’m most used to Python, Rust and JavaScript, and have never seriously worked in Perl) and thus don’t really get anything out of ack over ripgrep, without putting in a fair bit of effort to figure out what I need to do in a particular case. I’m more likely to feed the output through sed or vim if I want to rewrite it, actually!

I’m very glad that ack existed; it led the way with better tools, and I used it heavily for some years. Thanks for making it!

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#215

Post by geezerjay »

burntsushi wrote: post #119
jorvi wrote: post #105

Earlier quoted context omitted.

What's strange to me is that some of these new incarnations use different syntax and/or flags. If those were the same you get the advantage of migraters not having to relearn anything. It also allows for the beauty of aliasing the new tool to the old name!

There is a very simple response to this: if ripgrep were a 100% drop-in replacement for something like GNU grep, then there would be basically no point for it to exist in the first place. The whole point is that it is very similar but does some things differently that a lot of people consider "better." I imagine this is truish for the other tools mentioned in this thread as well. (And still other tools, like xsv, hav…

> if ripgrep were a 100% drop-in replacement for something like GNU grep, then there would be basically no point for it to exist in the first place.

That seems to miss a huge lesson: backward compatibility eases transition, new features retain users.

Therefore, your assertion makes only sense if there would be no point in attracting existing users to use a tool whose added value is entirely irrelevant.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#216

Post by geezerjay »

burntsushi wrote: post #91
j2kun wrote: post #90

Earlier quoted context omitted.

Who makes the decision on what gets standardized into the distro?

The people in charge of the distro. Governance structures vary. And sometimes it's not just about who gets to decide, but also, the technical work required to do it. People need to put in the work to make Rust applications packageable according to the distro's standards. YMMV.

I would add that if a distro aims for Unix compliance, it's obvious that there is no alternative to include certain utils.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#217

Post by burntsushi »

geezerjay wrote: post #215
burntsushi wrote: post #119

Earlier quoted context omitted.

There is a very simple response to this: if ripgrep were a 100% drop-in replacement for something like GNU grep, then there would be basically no point for it to exist in the first place. The whole point is that it is very similar but does some things differently that a lot of people consider "better." I imagine this is truish for the other tools mentioned in this thread as well. (And still other tools, like xsv, hav…

> if ripgrep were a 100% drop-in replacement for something like GNU grep, then there would be basically no point for it to exist in the first place. That seems to miss a huge lesson: backward compatibility eases transition, new features retain users. Therefore, your assertion makes only sense if there would be no point in attracting existing users to use a tool whose added value is entirely irrelevant.

It doesn't miss any lesson. It's a trade off. The headline feature involves a default mode of operation that's fundamentally incompatible with GNU grep. Full stop.

ripgrep is an evolution on ag, which in turn is an evolution on ack. All three tools have similar defaults, so in fact, ripgrep preserves some amount of backward compatibility with previously established tools in terms of the default mode of operation. Just not GNU grep.

This goes further in that the intersection between ripgrep's features/flags and GNU grep's features is quite large---certainly much larger than the differences between them, which is just another form of preserving backward compatibility. This was done on purpose for exactly the lesson you're claiming I missed: backward compatibility eases transition.

(The context of this conversation was a 100% backward compatible version of ripgrep with GNU grep. See my other comments on ROI. Just because I can argue against 100% backward compatibility doesn't mean I've missed the importance of backward compatibility.)

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#218

Post by kaushalmodi »

chrismorgan wrote: post #190
trashcan wrote: post #73

Earlier quoted context omitted.

ack: https://beyondgrep.com/

grep came, then ack-grep, then silver-searcher and a few others, finally ripgrep. For most purposes, ripgrep (the one written in Rust) is the best of all of these tools, typically being the fastest and also the most Unicode-compliant, with the main downside being its non-deterministic ordering of output (because it searches files in parallel). The only reason for using ack these days is if you’re already invested in…

ack still shines when I have a unique application to highlight one or more regex expressions in a log file because of its unique `--passthru` option, AND support of PCRE regex.

So I can have regex like 'abc\K(def)(?=ghi)'. That will highlight ONLY 'def' in the text but only if that string is preceeded by 'abc' and 'ghi' follows.

- ripgrep cannot do that as it does not support PCRE

ag support --passthrough, but I haven't yet felt the need to try that as ack --passthru has been baked into my workflow and aliases for ages.

I use ripgrep (rg) otherwise by default.

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#219

Post by burntsushi »

kaushalmodi wrote: post #218
chrismorgan wrote: post #190

Earlier quoted context omitted.

grep came, then ack-grep, then silver-searcher and a few others, finally ripgrep. For most purposes, ripgrep (the one written in Rust) is the best of all of these tools, typically being the fastest and also the most Unicode-compliant, with the main downside being its non-deterministic ordering of output (because it searches files in parallel). The only reason for using ack these days is if you’re already invested in…

ack still shines when I have a unique application to highlight one or more regex expressions in a log file because of its unique `--passthru` option, AND support of PCRE regex. So I can have regex like 'abc\K(def)(?=ghi)'. That will highlight ONLY 'def' in the text but only if that string is preceeded by 'abc' and 'ghi' follows. - ripgrep cannot do that as it does not support PCRE ag support --passthrough, but I have…

You don't need an explicit `--passthru` option. `rg '^|foo|bar|baz'` will print every line in the input while highlighting `foo`, `bar` and `baz`.

I'm pretty sure the PCRE lookaround support you're referring to is exactly what the GP meant by "Perl magic powers."

Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust

#220

Post by petdance »

burntsushi wrote: post #212
petdance wrote: post #210

Earlier quoted context omitted.

What do you mean by a "invested in a Perl workflow"? Do you mean "comfortable with Perl regexes"? Other reasons that you may want to use ack: * You want to define your own filetypes * You want to define your own output using Perl regexes * You need the portability of an uncompiled tool in a single source file that you can drop into your ~/bin when you can't install or compile anything on the box. * You don't want to…

I'd like to make a few clarifications if you don't mind! You can define your own file types with ripgrep on the command line (albeit not in a config file, so you end up needing a wrapper script or an alias). ripgrep has pre-compiled binaries that work out of the box on Windows, Mac and Linux. "Rust runtime" isn't really a thing. It's like you saying you don't want to deal with a C runtime.

Thanks for the clarifications. I was under the impression that Rust required a lot of tough infrastructure.

I'm glad to see that ripgrep lets you define your own types. That ripgrep does it with globbing vs. the ways that ack allows is just another of the differences between the tools that people have to decide about.

Post reply on HN