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

131–140 of 225 posts

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

#131

Post by zeotroph »

falcolas wrote: post #124

I'm sorry to be something of a negative Nancy - and I'm sure I'm a corner case - but this is not really an alternative to find. It's an alternative for your editor's fuzzy find and a better version of shell globs. The absense of -delete, -execdir, -mtime, and the ability to chain multiple patterns together for the non-trivial use-cases, means this is practically useless in most places where `find` is used in day-to-d…

> Not to mention the "opinionated" choice to ignore a dynamic set of files and directories

That has bitten me a few times when using `rg`. Sometimes (but not often enough to remember the switch) I want to grep a lot of binary .so files for a string and am left wondering why nothing was found before just replacing rg with grep. Just calling `TOOL PATTERN` without switches is the most intuitive thing, and there I agree with `fd` to make `fd PATTERN` the default. Unlike BSD find which always needs at least a `.` to function.

> chained patterns.

The -or/-and and are indeed nice, but the -prune logic should get an update. Maybe when fd grows from 80 to 90% of use cases.

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

#132

Post by on_and_off »

bm1362 wrote: post #63
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 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 love exa and have just mapped it to ls (and ll for exa -l ) .

That way I don't even have to learn the new command (or risk forgetting about ls / be frustrated when I can't use it).

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

#133

Post by bm1362 »

dozzie wrote: post #115
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.

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

I think I wasn’t clear, but a lot of people are harping on the specific use case I glibly mentioned.

To answer you, I meant on a Docker image build step- which is where you’d want to install the tool so it’s accessible to people debugging the application during the container run context.

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

#134

Post by mmirate »

burntsushi wrote: post #120
mmirate wrote: post #101

Earlier quoted context omitted.

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

> there is fundamentally an interest in the fact that something is written in Foo (and this may indeed depend on the nature of X).

That speaks to a deficit in human cognition, that slapping Foo's name on something makes it interesting only based on Foo's "shininess" rather than Foo's technical merits. Neophilia, perhaps?

Anyway. Go has been in roughly the same state of "another purposefully-boring Java-like, but instead of generics it has a different shade of OO and a full gamut of integer machine-types" for its entire life thusfar, which is why I've never understood most of its hype.

Rust, on the other hand, actually has some serious motivation to its learning curve and its developing ecosystem.

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

#135

Post by bm1362 »

coldtea wrote: post #112
jorvi wrote: post #105

Earlier quoted context omitted.

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.

I agree with you, the reason these new tools are useful is they’re much more intuitive than the esoteric flags that have built up over the last 30 years.

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

#136

Post by foo101 »

bm1362 wrote: post #63
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 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…

What surprises me is that even after 25 years of the Internet, we cannot bring in new tools into our environment (be it a remote box I ssh into or a trimmed down docker image) on the fly.

The popular package management tools rely heavily on FHS and like to install stuff into directories that require root permission.

Imagine if there was a tool that could download binaries of modern tools from a certain repo and install it to our ~/bin. Imagine if we could use new command line tools as easily as we can download a fully functional complex applications securely into a browser tab just by typing its URL!

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

#137

Post by setr »

mmirate wrote: post #134
burntsushi wrote: post #120

Earlier quoted context omitted.

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

> there is fundamentally an interest in the fact that something is written in Foo (and this may indeed depend on the nature of X). That speaks to a deficit in human cognition, that slapping Foo's name on something makes it interesting only based on Foo's "shininess" rather than Foo's technical merits. Neophilia, perhaps? Anyway. Go has been in roughly the same state of "another purposefully-boring Java-like, but inst…

I'd say there are two (positive) reasons to it, since it only really appears for newer languages that are just gaining popularity

1. An improved tool was made, and presumably was made easier by the language somehow. 2. The tool serves as example of larger product written in that language

Both facilitate further usage of the language (by evangelism), show the language as being up-to-snuff (production-viable), and the existence of this codebase acts as an example for others within that language community.

It's not so much the language makes this tool better, but for that particular community, that the language was used is important, possibly more so than the tool itself.

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

#138

Post by mmirate »

setr wrote: post #137
mmirate wrote: post #134

Earlier quoted context omitted.

> there is fundamentally an interest in the fact that something is written in Foo (and this may indeed depend on the nature of X). That speaks to a deficit in human cognition, that slapping Foo's name on something makes it interesting only based on Foo's "shininess" rather than Foo's technical merits. Neophilia, perhaps? Anyway. Go has been in roughly the same state of "another purposefully-boring Java-like, but inst…

I'd say there are two (positive) reasons to it, since it only really appears for newer languages that are just gaining popularity 1. An improved tool was made, and presumably was made easier by the language somehow. 2. The tool serves as example of larger product written in that language Both facilitate further usage of the language (by evangelism), show the language as being up-to-snuff (production-viable), and the…

> and presumably was made easier by the language somehow.

Right, and outside a few very narrow domains that are helped by the bolted-on concurrency, Go generally fails to deliver on those presumptions, for the same reasons that Java wouldn't if it were invented when Go was.

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

#139

Post by weaksauce »

nine_k wrote: post #116
weaksauce wrote: post #78

Earlier quoted context omitted.

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

Why it would be significantly better than using a pipe?

I have encountered edge cases with pipe and xargs. if there was something that made it simpler i'd be all for it. This project aims to make find usable and simpler so why not?

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

#140

Post by JelteF »

baby wrote: post #128
coldtea wrote: post #113

Earlier quoted context omitted.

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

I just tried ripgrep and it's faster and I think I like the output better :)

It is definitely faster. The ripgrep author did extremely extensive benchmarking to a lot of tools. For the most common usecase check out this section, but the rest of the article is very much worth a read as well: http://blog.burntsushi.net/ripgrep/#subtitles-literal
Post reply on HN