
Find Files (Ff) – File Search Utility in Rust - pvsukale3
https://github.com/vishaltelangre/ff
======
robert_foss
There's also fd[1], which is written in rust and is super fast.

[1] [https://github.com/sharkdp/fd](https://github.com/sharkdp/fd)

~~~
iruoy
I just did a little test. fd seems to be about 3 times as fast.

    
    
      Command      | Mean [ms]     | Min…Max [ms]
      -------------|---------------|---------------
      `fd .conf /` | 525.6 ± 17.7  | 505.3…552.0
      `ff .conf /` | 1760.8 ± 10.2 | 1744.6…1775.3

~~~
Someone1234
Looking at the code, I believe because fd uses a loop, and ff uses function
recursion to walk the path tree. Function recursion is easier to write, but
definitely has some overhead.

~~~
winstonewert
My experience is that if you have to maintain your own stack (which you'd need
to in order to recursively walk directories) its faster to use the builtin
stack than to implement your own.

Further, it seems that this would IO-bound not CPU-bound so whatever small
overhead exists in recursion vs iteration will not be noticeable.

I think the difference is rather that `fd` uses threads and `ff` does not.

~~~
vishaltelangre
> `fd` uses threads and `ff` does not.

Author here. This is true. ff does not use threads right now. I have started
learning Rust just a few days ago. I am not quite yet familiar with advanced
topics such as achieving parallelism using threads in Rust and other similar
stuff. My knowledge of Rust is limited at this moment and I struggled to get
the language concepts to work such as ownership, lifetimes, etc. I am sure
that I will be able to improvise the ff's performance by some extent by
gaining some more knowledge of Rust.

~~~
vishaltelangre
UPDATE: Now ff also uses threads to achieve parallelism.

------
madmax96
First, I have a problem with rewriting common utilities (like find, which also
supports more search functionality than regex) while changing flags (e.g. `i`
to ignore case to `s` - incidentally, grep also accepts `i` to ignore case).
It makes it harder to explore the system interactively, particularly for
beginners.

Second, the utility already exists, and this version is significantly slower:

    
    
      > time ./ff '.*.cpp' ~/src/ > /dev/null
      
      real 0m1.195s
      user 0m0.488s
      sys 0m0.671s
    
      > time find -E ~/src/ -type f -regex '.*.cpp'  > /dev/null
    
      real 0m0.880s
      user 0m0.407s
      sys 0m0.425s
    

But wait! This is a totally unnatural use of find. If we use find like users
actually do, we get even better performance:

    
    
      time find ~/src/ -name '*.cpp'  > /dev/null
    
      real 0m0.553s
      user 0m0.181s
      sys 0m0.363s
    

Hardly scientific. But it begs the question: who is this for?

~~~
setr
tbh find's command line interface is extremely unnatural, and that alone would
justify a switch for me. Ofc, there's no reason that the program itself needs
to be reimplemented beyond its argument parser, but that's not that concerning
for me as long as its still _fast enough_

------
imoverclocked
Here is a bash/zsh port:

alias ff='find . | egrep'

~~~
olejorgenb
This will show all files where _any_ of the path matches, not just the leafs

~~~
frutiger
`find . -type f -name "$1"` should give you that and potentially faster than
GP since you don't need to do any I/O to a second process.

------
nurettin
Why do "convert everything to rust" people appear to prefer solving already
solved problems instead of focusing on problems we could not solve but are now
possible thanks to Rust?

~~~
Dowwie
Have you used these command line utilities yet? They're great!

Exa, ripgrep, fd, bat, broot, ruplacer

And more...

~~~
iruoy
I'd recomend lsd over exa. Which I also use to replace tree. I haven't heard
of broot and ruplacer before, but they seem cool.

I've got this in my .zshrc:

    
    
      alias ls='lsd'
      alias tree='lsd --tree'

~~~
suprfnk
> lsd

Tangent, but man is that a bad name for a CLI tool. Had to add a lot of
keywords to not get drugs-related pages.

~~~
asark
"!gh lsd"

Though yes, many computer-thing names are bad in the search department.

------
wst_
Someone already opened an issue to make it ignore files specified in
`.gitignore`. A `fd` is doing it, `rg` is doing it, now someone wants this to
behave the same. I don't know. Maybe I have some really strange expectations
but when I want to find a file and nothing comes up as a result, I want to be
sure nothing is there. And I want to be sure without remembering bunch of
command line options or setting up aliases everywhere I log in because, guess
what, maybe they invented some other file with patterns to ignore. Is it only
me?

~~~
burntsushi
That's the great thing about these tools. There is no need to serve as
fundamental tools of a system that conform to some ancient spec like POSIX.
There is no need for that because those tools already exist and work well. So
if that's the behavior you want, then just use those tools. They work
exceptionally well when called by other programs, like shell scripts, because
they have reasonably standardized behavior.

But with these tools, we have the freedom to revisit old assumptions. One of
those is smart filtering. I can't tell you how many people tell me that they
enjoy that as a good default.

Tools should make the fact that they do smart filtering very clear, because it
can be surprising if you aren't expecting it. But otherwise, I'm not
particularly sympathetic to your reasoning here because: 1) what I said above
about standard tools being available and 2) these tools should have ways of
disabling smart filtering. So if it bites you, it should bite you only once.
After that, you either learn to like it, learn to setup an alias and forget
about it, or ragequit the tool.

------
saagarjha
How does this compare to fd, which provides similar functionality and is also
written in Rust?

~~~
vishaltelangre
I have answered a similar question here -
[https://github.com/vishaltelangre/ff/issues/4](https://github.com/vishaltelangre/ff/issues/4).

------
vram22
Here's a simple version of a file find command utility, written in D, minimal
features, may be useful for beginners to D:

Command line D utility - find files matching a pattern under a directory:

[https://jugad2.blogspot.com/2016/10/command-line-d-
utility-f...](https://jugad2.blogspot.com/2016/10/command-line-d-utility-find-
files.html)

The D stdlib's dirEntries() function makes the job easy, for a basic one like
this.

~~~
vram22
Also, related, a bunch of D command-line utilities, again may be good for
beginners to learn a bit from:

[https://news.ycombinator.com/item?id=18338952](https://news.ycombinator.com/item?id=18338952)

------
sagartewari01
What does this tool provide that I can't get from a wrapper around gnu find?

~~~
mbaeten
It might also be valuable to projects like Redox.

~~~
vishaltelangre
Related discussion -
[https://www.reddit.com/r/rust/comments/av31ae/ff_find_files_...](https://www.reddit.com/r/rust/comments/av31ae/ff_find_files_by_name/ehcanyn/).

------
chewbacha
That’s fun! I needed something like this and wrote my own a while ago. Choose
to implement it with a different algorithm though instead of regex.

[https://github.com/kbacha/file-finder](https://github.com/kbacha/file-finder)

