It's strange to advertise this as a find(1) replacement when it covers maybe 1% of find(1) use cases. find -type d -empty -delete find -type l -exec readlink -f {} + etc. are not covered at all.
1% of possible cases but 90% of actual usage I'd say
Show HN: A simple, fast and user-friendly alternative to find, written in Rust
61–70 of 225 posts
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#62Any 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.
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#63It 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)…
I appreciate all these new incarnations of old school tools but end up sticking with the basics regardless. When I'm sshing into a box to figure out whats going on, my toolset is mostly limited to top, find, xargs, awk, grep, df, du etc. Even local development now, I'm mostly debugging on a docker container running alpine or ubuntu.
Knowing the right incantations is useful in that context and keeps me from installing better tools until they become part of the distro we deploy with.
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#64It 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)…
It would be even nicer to have an opensource project that pushes a set of these tools, that then can get picked up by the distros such that in 5 year you can expect these all to be included at a reasonable version such that you do not have to install them by hand on each machine that you land on.
On the other hand, you may want to keep some smart dotfiles around that installs them in ~/bin
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#65It 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)…
I appreciate all these new incarnations of old school tools but end up sticking with the basics regardless. When I'm sshing into a box to figure out whats going on, my toolset is mostly limited to top, find, xargs, awk, grep, df, du etc. Even local development now, I'm mostly debugging on a docker container running alpine or ubuntu. Knowing the right incantations is useful in that context and keeps me from installing…
> When I'm sshing into a box to figure out whats going on, my toolset is mostly limited to top, find, xargs, awk, grep, df, du etc.
I wrote some of the tools on coldtea's list, and I'm pretty much the same way in that I stick to distro tooling in vanilla setups. But I spend enough time on my local workstation that having "better" (read: creature comforts) is worth it there! But yeah, if you spend most of your time in vanilla setups, then tools not in the standard distro repos are a hard sell.
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#66It's strange to advertise this as a find(1) replacement when it covers maybe 1% of find(1) use cases. find -type d -empty -delete find -type l -exec readlink -f {} + etc. are not covered at all.
1% of possible cases but 90% of actual usage I'd say
Then you have a different usage pattern than I do. For simple name globbing, I usually just use shell globs, e.g.
ls src/**/*_test.go
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#67How does it compare in speed to 'ag' (i.e the silver searcher) -g option?
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 totalRe: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#68For 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…
Awesome. Sorry I should’ve dug a little deeper before commenting. Nice job on the multithreading also!
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#69It 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)…
I appreciate all these new incarnations of old school tools but end up sticking with the basics regardless. When I'm sshing into a box to figure out whats going on, my toolset is mostly limited to top, find, xargs, awk, grep, df, du etc. Even local development now, I'm mostly debugging on a docker container running alpine or ubuntu. Knowing the right incantations is useful in that context and keeps me from installing…
>I appreciate all these new incarnations of old school tools but end up sticking with the basics regardless. When I'm sshing into a box to figure out whats going on, my toolset is mostly limited to top, find, xargs, awk, grep, df, du etc.
That's why I wrote about it being nice to have them all in distros -- perhaps in a single package like coreutils.
Then wherever you are, they'd be just a "package-manager install rustutils" away.
Generally, if one is not an admin of random hodgepodge of systems (e.g. in big enterprises), then you are:
(1) doing work on your own workstation
(2) administering machines you control the provision (e.g. a person administering a startup's Cloud servers)
(3) doing development on some kind of vm
In those cases you can quite easily install a bundle package and make sure those tools are there.
I, for one, don't go out in unknown systems day after day -- even if we have 100s of servers we manage, we DO manage them.
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#70I'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.
It's not a find replacement at all, even!
fzf just actually calls find by default, so a naked call to fzf will actually give you the same results as find | fzf.
Search specifically for directories, that's find -type d | fzf.