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

It would be nice to have a collection of modern&#x2F;faster&#x2F;saner alternatives to common unix tools and such utilities (made in rust or not) that becomes standard -- or at least easily installable in linux distros and OS X. Not for replacing those tools, but for supplementing them.<p>Thinking of stuff like fd and:<p>ripgrep: <a href="https:&#x2F;&#x2F;github.com&#x2F;BurntSushi&#x2F;ripgrep" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;BurntSushi&#x2F;ripgrep</a> (grep&#x2F;ag alt)<p>xsv: <a href="https:&#x2F;&#x2F;github.com&#x2F;BurntSushi&#x2F;xsv" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;BurntSushi&#x2F;xsv</a> (csv tool)<p>exa: <a href="https:&#x2F;&#x2F;the.exa.website&#x2F;" rel="nofollow">https:&#x2F;&#x2F;the.exa.website&#x2F;</a> (ls)<p>una: <a href="https:&#x2F;&#x2F;github.com&#x2F;jwiegley&#x2F;una" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jwiegley&#x2F;una</a> (multi-compression utils wrapper)<p>tokei: <a href="https:&#x2F;&#x2F;github.com&#x2F;Aaronepower&#x2F;tokei" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Aaronepower&#x2F;tokei</a> (loc stats)<p>And of course this: <a href="https:&#x2F;&#x2F;github.com&#x2F;uutils&#x2F;coreutils" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;uutils&#x2F;coreutils</a>

I&#x27;m sorry to be something of a negative Nancy - and I&#x27;m sure I&#x27;m a corner case - but this is not really an alternative to find. It&#x27;s an alternative for your editor&#x27;s fuzzy find and a better version of shell globs.<p>The absense of -delete, -execdir, -mtime, and the ability to chain multiple patterns together for the non-trivial use-cases, means this is practically useless in most places where `find` is used in day-to-day work. Not to mention the &quot;opinionated&quot; choice to ignore a dynamic set of files and directories (what files were skipped? In any directory, or just git repos? Does it back track to find a git directory and .gitignore? Does it query out to git? Does it respect user&#x2F;global .gitignore settings? Does it skip Windows hidden files from a unix prompt, or a dotted file when on Windows?), the options hidden behind two separate flags.<p>Perhaps it&#x27;s just because I&#x27;m used to using &#x27;find&#x27;, but when I reach for it, it&#x27;s because I need -delete or -execdir, or I&#x27;m writing automation that really needs -mtime and chained patterns.<p>So, I would suggest that you don&#x27;t call this an alternative to find; it&#x27;s not. A replacement for shell globs, sure. A replacement for poor file finding in text editors, OK. Just... not find.<p>EDIT: Oh, &#x27;fd&#x27; also already exists. <a href="https:&#x2F;&#x2F;github.com&#x2F;knu&#x2F;FDclone" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;knu&#x2F;FDclone</a>

Yes I&#x27;ll agree with the people who say that this isn&#x27;t a drop in replacement (fewer features and different syntax) but I also just don&#x27;t care. fd&#x27;s defaults are brilliantly simple and just plain make sense. Yes I can use find but I always, always end up looking up an example. fd was simple enough that I very quickly figured it out by trial and error. And it really is fast.<p>Thank you sharkdp -- really nicely done. Appreciated.

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

Any plan to provide find compatibility for drop-in replacement? My find&#x2F;locate usage patterns are not worth learning new sophisticated tool for 5sec speedup once a week, and I suspect that I’m not alone. This is the main problem of new tools — not repeating the old-familiar style makes it unattractive for non-aggressive users.<p>Side question: why is speed important? Which tools use fd to gain required performance?

IMHO, there is no demand for this kind of &quot;improved tools collection&quot;. In the programming world, the programmer creates a sweet working environment to fit his needs by creating many alias and functions, by customizing his desktop. He complains that the tools collection is complex but has no opportunity to progress because he rarely uses them directly. In the &quot;sysop&quot; world, the user is always logged remotely on varying machines. There is no incentive to install and customize a machine because he will quickly have to work on another machine without this customization.<p>I think we need a saner alternative to the man pages of the classic unix tools collection. Something less focus on the seldom used options, but more focus on the traps to avoid and the useful tricks. The bad quality of documentation is more annoying than the incongruous syntax of tools.

For me, the speed of find and grep is sufficiently never a concern, so I do not find these speedy alternatives sufficient to compensate for its non-universality. And when the speed of grep and find do become a concern, I would think the issues are somewhere else -- like have 10s thousands of jpg files scatter everywhere that you need to find in the first place. When issues are somewhere else, replacing it with <i>better</i> tool only hides and makes the problem worse.

It&#x27;s strange to advertise this as a find(1) replacement when it covers maybe 1% of find(1) use cases.<p><pre><code> find -type d -empty -delete find -type l -exec readlink -f {} + </code></pre> etc. are not covered at all.

It is incredibly fast! Thanks a lot for this great tool!

How does it compare in speed to &#x27;ag&#x27; (i.e the silver searcher) -g option?

I&#x27;ve found that fzf has replaced all uses of find for me except in scripts. fzf has the benefits of being bound to a single key binding and showing me results as I type, rather than after the command runs.

Why is this faster then find?

It&#x27;s exciting to see so many problem solvers use Rust to improve core linux utilities. I&#x27;ve been using Exa as an &#x27;ls&#x27; replacement for some time now. &#x27;fd&#x27; looks promising but has room to grow, still. Finding a file and then acting upon it is an important feature that ought to be addressed.

I&#x27;m honestly wondering when will we have the whole coreutils rewritten in Rust.

ripgrep, exa and now fd... any other CLI tools I should cargo-install?

I wonder how this compares to the speed of zsh&#x27;s globbing, which is what I&#x27;ve mostly switched to using instead of find.

For the benchmarks did you clear the page cache inbetween runs? It’s crazy fast and seems a little suspect

hey david, you can omit the &#x27;static lifetime in the root directory string declarations if you want!<p><a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rfcs&#x2F;pull&#x2F;1623" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rfcs&#x2F;pull&#x2F;1623</a>

&gt; Ignores patterns from your .gitignore, by default.<p>Do you need to be in the current git directory for this to happen, or all git dirs that happen to be traversed?<p>And are you using an NFA based regex engine?

Will we ever be able to promote a tool without talking about the programming language it is implemented in?

Pet: <a href="https:&#x2F;&#x2F;github.com&#x2F;knqyf263&#x2F;pet" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;knqyf263&#x2F;pet</a> and Peco: <a href="https:&#x2F;&#x2F;github.com&#x2F;peco&#x2F;peco" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;peco&#x2F;peco</a>