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

111–120 of 225 posts

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

#111

Post by HankB99 »

jhasse wrote: post #86
bm1362 wrote: post #82

Earlier quoted context omitted.

Just my experience, I'm sure there are other types of organizations. In most of my workplaces, having one developer's preferred tools installed as a build step might not pass review. I would be annoyed if fish was installed on all our prod boxes, for example. I'm glad these tools work for you and I hope the community keeps making them, I just threw in my perspective.

> I would be annoyed if fish was installed on all our prod boxes, for example. Why?

'fish' I take it is a shell (of which I remain ignorant.) I suppose that at the very least, it increases the attack surface on an installation and either makes security harder or the system less secure.

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

#112

Post by coldtea »

jorvi wrote: post #105
burntsushi wrote: post #65

Earlier quoted context omitted.

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

What's strange to me is that some of these new incarnations use different syntax and/or flags. If those were the same you get the advantage of migraters not having to relearn anything. It also allows for the beauty of aliasing the new tool to the old name!

>If those were the same you get the advantage of migraters not having to relearn anything.

You'd also loose the ability to improve upon arcane/ad-hoc and obsolete flags and syntax choices though too.

And for the "same flags" to make any sense, you'd also be constrained to produce the same output and even recreate the same quirks.

At which point, might as well just use the originals.

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

#113

Post by coldtea »

baby wrote: post #108
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)…

I've always used cloc instead of tokei: https://github.com/AlDanial/cloc I use "x" in oh-my-zsh plugins instead of una. https://github.com/robbyrussell/oh-my-zsh/tree/master/plugin... I use "ag" instead of ripgrep. https://github.com/ggreer/the_silver_searcher I use "fpp" instead of vgrep. https://github.com/facebook/PathPicker Anybody has tried them and has an opinion on which is better?

I've tried ag and ripgrep. ripgrep is better.

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

#114

Post by tyingq »

zestyping wrote: post #109
sharkdp wrote: post #27

Earlier quoted context omitted.

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

Interesting. Why does multithreading make a big difference? I would have assumed that disk seek latency was the speed-limiting factor; what am I missing?

I believe the comparative benchmarks are done with the os file caches already primed.

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

#115

Post by dozzie »

bm1362 wrote: post #82
coldtea wrote: post #69

Earlier quoted context omitted.

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

Just my experience, I'm sure there are other types of organizations. In most of my workplaces, having one developer's preferred tools installed as a build step might not pass review. I would be annoyed if fish was installed on all our prod boxes, for example. I'm glad these tools work for you and I hope the community keeps making them, I just threw in my perspective.

Why would you run build step on production servers at all?

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

#116

Post by nine_k »

weaksauce wrote: post #78
sharkdp wrote: post #57

Earlier quoted context omitted.

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?

Why it would be significantly better than using a pipe?

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

#117

Post by snorrah »

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

Ideally it would be nice if common utils were redeveloped to have optimisations that weren’t thought of or available back in the day

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

#118

Post by cookiecaper »

sharkdp wrote: post #57
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 i…

The most annoying part of find, for me, is stuff like exclusions, with `-prune -o ... -print`. Something like rsync's `--exclude` would be great.

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

#119

Post by burntsushi »

jorvi wrote: post #105
burntsushi wrote: post #65

Earlier quoted context omitted.

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

What's strange to me is that some of these new incarnations use different syntax and/or flags. If those were the same you get the advantage of migraters not having to relearn anything. It also allows for the beauty of aliasing the new tool to the old name!

There is a very simple response to this: if ripgrep were a 100% drop-in replacement for something like GNU grep, then there would be basically no point for it to exist in the first place. The whole point is that it is very similar but does some things differently that a lot of people consider "better." I imagine this is truish for the other tools mentioned in this thread as well. (And still other tools, like xsv, have no pre-existing standard. Standard UNIX tooling doesn't work on CSV.)

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

#120

Post by burntsushi »

mmirate wrote: post #101
dysoco wrote: post #87

Earlier quoted context omitted.

Yeah when it's written in Python or C and not Go/Rust.

Aye, that's because being written in Python, C or Go is - in my eyes - a strike against the project in an absolute sense, because it will be more buggy and difficult to maintain due to lacking the functional-programming abstractions and powerful static-type system of a good ML descendant such as Rust or OCaml. (Or of Haskell, but it tends to lack the practicality of the ML family.) So of course one does not trumpet t…

I don't buy it. People say, "X (written in Foo)" because there is fundamentally an interest in the fact that something is written in Foo (and this may indeed depend on the nature of X). Back when Go was new and shiny, it was the same situation.[1] :-)

[1] - https://news.ycombinator.com/item?id=4685594

Post reply on HN