sharkdp

Thank you for the feedback.

> So, I would suggest that you don't call this an alternative to find; it's not. A replacement for shell globs, sure. A replacement for poor file finding in text editors, OK. Just... not find.

It's literally called "a simple [..] alternative to find" and the very first sentence in the README says that "it does not seek to mirror all of find's powerful functionality". I'm not sure anymore how far I have to back off until everyone will be okay with my "advertising" :-)

> Another elitist aside: I can usually tell that I won't want to use a tool when it has a mac os install option first under the downloads section on its page.

This is only because it's so much harder to support every possible Linux distro. I actually don't use macOS on my own, but 'Homebrew' seems like a really nice package manager. (Also, the first install option is via "cargo" which is platform independent.)

Thank you for the hint! Unfortunately, this is not in rust 1.16, which I currently still want to support.

zsh globs are about a factor of 5 slower (for this example):

    > time fd -sIe jpg > /dev/null
    1,24s user 0,77s system 758% cpu 0,265 total
    
    > time ls ~/**/*.jpg > /dev/null
    0,53s user 0,97s system 98% cpu 1,518 total

I'm not entirely sure, yet, but I'd be happy to discuss this. A GitHub ticket would be the best place (https://github.com/sharkdp/fd/issues).

Thank you for the feedback, I'm glad you like it!

fd is about a factor of 2-3 faster (for this example):

    > time fd -HIe jpg > /dev/null                     
    5,12s user 2,03s system 785% cpu 0,911 total
    
    > time ag --depth 100 -uuu -g '\.jpg$' > /dev/null
    0,95s user 1,66s system 99% cpu 2,628 total

Thank you for the feedback.

No, fd does not aim to be a drop-in replacement for find. It was actually designed as a "user-friendly" (I know, I know...) alternative to find for most of the use-cases: "fd pattern" vs. "find -iname 'pattern'", smart case, etc. Also, in my view, the colored output is not just a way to make it look fancy, but actually helps a lot when scanning a large output in the terminal.

The speed is not hugely important to me, but I wanted it to be at least comparably fast to find (that's why I decided to try out Rust for this project). Otherwise, nobody would even consider using it.

I know that it will not be for everyone and I also know that it's a lot to ask someone to learn a new tool, but I'm happy if there are some people that enjoy using it. I certainly do ;-)

> Did you do a benchmark with `--threads 1`?

I did. You are right, multi-threading does not give a linear speed up, but it makes fd about a factor of three faster on my machine (8 virtual cores). With `--threads 1`, fd is on-par with 'find -iname', but still faster than 'find -iregex'.

Yes. For simple searches, the main reason is that 'fd' walks the directory tree in a multithreaded fashion (thanks to the 'ignore' crate).

Thank you for the feedback! Most of the credit for the speed goes to the amazing Rust modules 'ignore' and 'regex', which are also used by ripgrep (https://github.com/BurntSushi/ripgrep).

It will work for all git directories that are encountered. This behavior can be disabled with the '-I' flag, if needed.

fd uses Rusts regex engine (https://github.com/rust-lang/regex) which is based on finite automata.

Thank you for the feedback!

'-exec' is not supported at the moment. It's definitely something I would consider adding.

We do have '-0'/'--print0' to separate results by NULL, so 'fd' can be used in combination with 'xargs'.

Thank you for the feedback!

The benchmarks that are mentioned in the README are performed for a "warm cache", i.e. I'm running one of the tools first to fill the caches. Then, I'm performing multiple runs of each tool (using bench for some nice statistics) such that both tools profit from the warmed-up cache.

I also perform other benchmarks where I clear the caches. In this case, 'fd' is usually even faster.

The scripts for both warm and cold cache are here: https://gist.github.com/sharkdp/4bc3e5f5ea9df2f29c02ede50634...

calories are supported now

calories are supported now.

lightyears and parsecs are here, now.

lightyears, (atto)parsecs and fortnights are now supported.

rpm are supported now. Thanks.

floz and fluidounce are now supported.

calories are supported now.

Thank you. Same request is tracked here: https://github.com/sharkdp/insect/issues/86

That would be great.

Thank you for the feedback. What do you mean by "specifying output units"? Insect has the "->" operator which does that:

  40000 km / c -> ms

   = 133.426 ms

Thanks! I'm glad you like it.

Thank you for the feedback!

1. Yes, I'll definitely add calories, good suggestion.

2. Yes, that's probably a good idea. I should distinguish constants and (user-defined) variables.

> I'm a little confused as to how this improves on GNU units, which seems to support far more [...]

> is it supposed to be a competitor? learn how to use a new language? I don't get it.

No reason to be confused. GNU units is a great tool. qalculate and speedcrunch are great, too. Insect is just my take at it. Each of these tools has advantages and disadvantages. As for insect, one of the advantages for me is that it is platform-agnostic and can be used from anywhere without installation. The "You have: X; You want: Y" interface is basically replaced by "X -> Y".

Thank you. I'll add one of those.

In your first example, the result of the calculation is dimensionless (length divided by length), so it does not require any unit. It's a scalar value.

In your second example, the input gets parsed as "1/(2km)" which is equal to "0.5 km⁻¹". If you wanted half a kilometer, you'd have to enter "1/2*km"

I thought about it for some time and decided not to add Celsius and Fahrenheit: https://github.com/sharkdp/insect/issues/68

They are useful, of course, when it comes to simple unit conversions. But they lead to all kinds of problems if you start using them in calculations (which is what Insect is mostly for).