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

51–60 of 225 posts

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

#51

Post by romgrk »

wruza wrote: 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?

The other big advantage is `more user-friendly`. Thus no backward compatibility. No doubt some people are used to the old patterns, but lots of people also prefer saner defaults.

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

#52

Post by empath75 »

coldtea wrote: 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)…

Redox already has a core untils library.

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

#53

Post by pm215 »

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.

You need it if you want to modify the directory structure that find is traversing, so as to affect subsequent traversal, eg http://www.chiark.greenend.org.uk/~pmaydell/find/primes (cheatsheet here: http://www.chiark.greenend.org.uk/~pmaydell/find/primes-comm...)

Admittedly I wrote that nearly 20 years ago so I guess it doesn't invalidate your point :-)

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

#54

Post by foota »

wruza wrote: 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?

It's probably the "I'm searching the entire disk for something" use case.

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

#55

Post by wruza »

romgrk wrote: post #51
wruza wrote: 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?

The other big advantage is `more user-friendly`. Thus no backward compatibility. No doubt some people are used to the old patterns, but lots of people also prefer saner defaults.

I couldn’t use neither thing without man page for the first time. And remembering -name -iname -type* and -I -s comes only with practice.

* does fd find files by type, mtime, depth, logical operators? I missed that in readme. If not, maybe “just pattern” argument is not too fair at all.

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

#56

Post by _lbaq »

romgrk wrote: post #51
wruza wrote: 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?

The other big advantage is `more user-friendly`. Thus no backward compatibility. No doubt some people are used to the old patterns, but lots of people also prefer saner defaults.

I agree, but replacing find would be very hard, not only does people except it to work in a certain way, but tons of shell scripts also.

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

#57

Post by sharkdp »

wruza wrote: 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 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 ;-)

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

#58

Post by kuwze »

coldtea wrote: 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)…

vgrep: https://github.com/fmthoma/vgrep (Haskell vertical grep)

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

#59

Post by nerdponx »

coldtea wrote: 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)…

Does the Fish shell count?

Consider also the "fuzzy finder" FZF.

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

#60

Post by sa46 »

pmoriarty wrote: post #48
z1mm32m4n wrote: post #42

I'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.

fzf is fine for searching just for filenames, but it does nothing else that find does. It can't even search specifically for directories, as far as I can see, nevermind searching for files/dirs with certain permissions, ages, etc. It's also uselesss for non-interactive uses such as scripting. I like fzf, but it's really not anywhere close to a complete find replacement.

You're right that fzf doesn't replace find. Fzf is just an interactive, filtering tool. You can pipe anything into it. find is a common way of populating it with data.

I suspect the GP meant that fzf replaced the pattern 'find |xargs $binary' for small interactive use cases. It's much nicer to do '$binary '. I use fzf the same way with key bindings to select directories and files powered by find.

Post reply on HN