Live data from Hacker News

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

github.com

71–80 of 225 posts

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

#71
post #41

Any plan to provide find compatibility for drop-in replacement? My find/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. Side question: why is speed important? Which tools use fd to gain required performance?

I see the speed as a secondary concern relative to the simplified interface. This tool looks like it covers about 99% of my usage of find with a much simpler and terser syntax, and I'm looking forward to trying it.

It is interesting if

  alias fd=“function _fd(){find . -iregex ‘.*’$1’.*’};_fd”
would suffice for these 99? (not tested, but hope you got the idea)

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

#72
post #28
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.

What about commands which only take a single file as input? Is xargs -n1 noticeably faster than -exec? (And if it is, is that actually worth it for clarity's sake?)

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

#73
post #17

It would be nice to have a collection of modern/faster/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. Thinking of stuff like fd and: ripgrep: https://github.com/BurntSushi/ripgrep (grep/ag alt) xsv: https://github.com/BurntSushi/xsv (csv tool)…

ack: https://beyondgrep.com/

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

#74
post #38

Earlier quoted context omitted.

What exactly do you think was bullshit here?

The fact that Rust is used is uninteresting, considering there's nothing special about it as it pertains to the other advertised features. "Bullshit" might be strong, but "trivia relevant only to a person interested in fomenting language flamewars" isn't a stretch.

> The fact that Rust is used is uninteresting, considering there's nothing special about it as it pertains to the other advertised features.

Considering the fact that a programming language's appeal is directly influenced by the size and accomplishments of its community, I'd say it's relevant.

A high level, systems programming, relative new language is used to write software that outperforms the default tools. That's proof that the language has potential and encourages people to try it out. It's how languages and communities grow. If you think it's uninteresting, that's your subjective opinion, and you're free to dismiss it. It certainly doesn't make the language, the project or the title "bullshit" or "trivia relevant only to [...] language flamewars".

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

#76
post #17

It would be nice to have a collection of modern/faster/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. Thinking of stuff like fd and: ripgrep: https://github.com/BurntSushi/ripgrep (grep/ag alt) xsv: https://github.com/BurntSushi/xsv (csv tool)…

httpie: https://github.com/jakubroztocil/httpie (http client)

jq: https://stedolan.github.io/jq/ (lightweight JSON client)

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

#77
post #12

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

una ( https://github.com/jwiegley/una ), a universal unarchiver which handles choosing between tar, unzip, etc. for you.

You can't install this with cargo. Una is a Haskell program; you can get it with `stack install una`.

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

#78
post #57
post #41

Any plan to provide find compatibility for drop-in replacement? My find/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. Side question: why is speed important? Which tools use fd to gain required performance?

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

any plans on implementing the exec command from find in fd?

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

#79
Yes I'll agree with the people who say that this isn't a drop in replacement (fewer features and different syntax) but I also just don't care. fd'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.

Thank you sharkdp -- really nicely done. Appreciated.

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

#80
post #5

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

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

> using bench for some nice statistics

'bench' turns out to be this tool: https://github.com/Gabriel439/bench

It seems to be quite useful, and I was not aware of it, thanks! Would probably be nice to have it packaged in distributions...

Post reply on HN