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

101–110 of 225 posts

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

#101

Post by mmirate »

dysoco wrote: post #87
Karrot_Kream wrote: post #75

Will we ever be able to promote a tool without talking about the programming language it is implemented in?

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 that one's project is written in Python, C or Go.

n.b. I said "absolute sense" because all of this this is, of course, inapplicable when searching for libraries specifically for a language such as Python, C, or Go.

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

#102

Post by seagreen »

rahiel wrote: post #77
seagreen wrote: post #15

Earlier quoted context omitted.

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`.

Whoops, good point. In the long run I think Una's a good candidate for being installed at the systems level, because you really want to install unzip, etc. along with it.

EDIT: The idea being that if you install it with your system package manager it can have unzip etc. as dependencies so that's taken care of automatically.

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

#103

Post by jasonm23 »

nemild wrote: post #76
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)…

httpie: https://github.com/jakubroztocil/httpie (http client) jq: https://stedolan.github.io/jq/ (lightweight JSON client)

Pup deserves a mention too.

https://github.com/ericchiang/pup

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

#104

Post by raimue »

seagreen wrote: post #15
adwhit wrote: 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 could just use bsdtar from libarchive, which handles all the compression and archive formats automatically without additional tools.

https://github.com/libarchive/libarchive/wiki/LibarchiveForm...

GNU tar is so limited, but unfortunately still the default on most systems.

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

#105

Post by jorvi »

burntsushi wrote: post #65
bm1362 wrote: post #63

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

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!

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

#106

Post by ktRolster »

dibujante wrote: post #99
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…

You could always add a --back(wards compatible) parameter that caused it to parse every other parameter like a `find` :)

You can also add the --back option as an alias, so you don't need to type it in every time on systems where that is important. You could also use an environment variable to modify the behavior.

The GNU team did this when they added or changed behavior to the original tools. A lot of them have flags like -posix and such which give them a strict set of behaviors.

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

#107

Post by sidlls »

rootlocus wrote: post #74
sidlls wrote: post #38

Earlier quoted context omitted.

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…

There is nothing interesting about the performance improvement that is a product of using a particular language, and particularly this language. It may as well have been written in Java or Haskell.

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

#108

Post by baby »

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?

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

#109

Post by zestyping »

sharkdp wrote: post #27
tyingq wrote: post #23

Earlier quoted context omitted.

"Concerning fd's speed, the main credit goes to the regex and ignore crates that are also used in ripgrep"

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?

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

#110

Post by keenerd »

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

How about better but only in a very specific way?

gz-sort: http://kmkeen.com/gz-sort/

Post reply on HN