4 ms·

> As much as i love new rust cli tools Why would you love them just because they're in rust? I'd like to praise the author of this fd for not having "Rust" al

> As much as i love new rust cli tools Why would you love them just because they're in rust? I'd like to praise the author of this fd for not having "Rust" all over the web page or in the HN link, actually. The Rust inquisition would get far less pushback if instead of threatening people that god will kill a kitten every time you use a non-kosher programming language, they'd promote software that improves (even opinionated improves, like this fd) on existing tools instead of having its main feature "but it's written in Rust!".

agumonkey 2y ago
performance for a start especially in the case of fd, it's way faster than gnu find sorry if that annoys people, but a rust tool starts with a high trust in my mind that it will fly ps: to show i'm not in full fanboy mode, i'm often surprised that fzf, brilliant and performant tool, is written in go, but i know it's not rust :)
- nottorp 2y ago
  > especially in the case of fd, it's way faster than gnu find ... also the only tool written in Rust that made it to HN lately that does not scream "I'm written in Rust!" everywhere :) It also aims to improve on gnu find, not to reimplement it because it's in a non approved language. It's what the Rust evangelists aren't.
- alp1n3_eth 2y ago
  Surprisingly, Go is great for CLI tooling. It may not have the insane speed that carefully planned and written Rust does, but it's very easy to write and be performant without even needing to go to great lengths to optimize it. I generally say that anything under 500ms is good for commands that aren't crunching data, and even Python CLI tools can come in under that number without too much effort.
  - bbkane 2y ago
    Unfortunately, Python CLI startup time is correlated with how many files the interpreter has to interpret, which usually takes effort to combat, so larger CLIs that have a lot of functionality and thus files always seem to slow down. The Azure CLI is a good example of this. It's been a year or two since I used it, so maybe it's improved since then, but it used to take a second or two just to run `az --help`, which infuriated me. If you own a slow Python CLI, look into lazily importing libraries instead of unconditionally importing at the top of each Python file. I've seen that help a lot for slow Python CLIs at $DAYJOB
chrisweekly 2y ago
That's a bit extreme. I'm not who you replied to, but IME, things written in rust tend to be fast and sane. All else equal, "written in rust" is a positive signal to me.
stouset 2y ago
That is literally what people are doing. “Written in Rust” has become a pretty convenient shorthand for “this was written by someone who cares deeply about quality, and you can guess that it will be extremely fast, relatively free of bugs, and use as many cores as you want to throw at it”. While you’re out here complaining, the Rust community has built a truly impressive array of improved, human-focused command line tools (rg, bat, fd, hyperfine, delta, eza, and on and on) and a bunch of best-in-class libraries for building tools (regex comes to mind).
- dietr1ch 2y ago
  The ecosystem enables focusing on the task at hand. It's great that you don't need to get side-tracked at every single step. There's many high quality libraries.
- BoingBoomTschak 2y ago
  While mostly true, there's a large problem with lots of these Rust CLI tools (and I use some of them, don't misunderstand me): they often discard the UNIX philosophy in favour of newbie friendliness and glitter. For example, ripgrep shouldn't merge find and grep (actually, I use a personal wrapper around `find ... -exec grep ... {} +` because my only beef with this is that find's syntax to exclude stuff is horrible, https://git.sr.ht/~q3cpma/scripts/tree/master/item/find_grep https://git.sr.ht/~q3cpma/scripts/tree/master/item/find_grep). Or you see something like https://github.com/shssoichiro/oxipng/issues/629 https://github.com/shssoichiro/oxipng/issues/629 because people don't even know how to use xargs... Feels like if someone did a RIIR on ImageMagick, it'd be able to talk with Instagram and Flickr by itself or process RAW files like Darktable. Would probably have some kind of tagging system too.
  - bbkane 2y ago
    I personally appreciate the newbie friendliness and glitter, and even the "make the common case easier at the expense of composability" tradoff, though I think tlmost of these tools are still relatively composable.
  - burntsushi 2y ago
thiht 2y ago
> Why would you love them just because they're in rust? That's not it. People love the new rust tools because they're great tools with sane defaults. They happen to be written in Rust most of the time and that's it so people use this to describe them.

agumonkey 2y ago

performance for a start especially in the case of fd, it's way faster than gnu find sorry if that annoys people, but a rust tool starts with a high trust in my mind that it will fly ps: to show i'm not in full fanboy mode, i'm often surprised that fzf, brilliant and performant tool, is written in go, but i know it's not rust :)

nottorp 2y ago
> especially in the case of fd, it's way faster than gnu find ... also the only tool written in Rust that made it to HN lately that does not scream "I'm written in Rust!" everywhere :) It also aims to improve on gnu find, not to reimplement it because it's in a non approved language. It's what the Rust evangelists aren't.
alp1n3_eth 2y ago
Surprisingly, Go is great for CLI tooling. It may not have the insane speed that carefully planned and written Rust does, but it's very easy to write and be performant without even needing to go to great lengths to optimize it. I generally say that anything under 500ms is good for commands that aren't crunching data, and even Python CLI tools can come in under that number without too much effort.
- bbkane 2y ago
  Unfortunately, Python CLI startup time is correlated with how many files the interpreter has to interpret, which usually takes effort to combat, so larger CLIs that have a lot of functionality and thus files always seem to slow down. The Azure CLI is a good example of this. It's been a year or two since I used it, so maybe it's improved since then, but it used to take a second or two just to run `az --help`, which infuriated me. If you own a slow Python CLI, look into lazily importing libraries instead of unconditionally importing at the top of each Python file. I've seen that help a lot for slow Python CLIs at $DAYJOB

chrisweekly 2y ago

That's a bit extreme. I'm not who you replied to, but IME, things written in rust tend to be fast and sane. All else equal, "written in rust" is a positive signal to me.

stouset 2y ago

That is literally what people are doing. “Written in Rust” has become a pretty convenient shorthand for “this was written by someone who cares deeply about quality, and you can guess that it will be extremely fast, relatively free of bugs, and use as many cores as you want to throw at it”. While you’re out here complaining, the Rust community has built a truly impressive array of improved, human-focused command line tools (rg, bat, fd, hyperfine, delta, eza, and on and on) and a bunch of best-in-class libraries for building tools (regex comes to mind).

dietr1ch 2y ago
The ecosystem enables focusing on the task at hand. It's great that you don't need to get side-tracked at every single step. There's many high quality libraries.
BoingBoomTschak 2y ago
While mostly true, there's a large problem with lots of these Rust CLI tools (and I use some of them, don't misunderstand me): they often discard the UNIX philosophy in favour of newbie friendliness and glitter. For example, ripgrep shouldn't merge find and grep (actually, I use a personal wrapper around `find ... -exec grep ... {} +` because my only beef with this is that find's syntax to exclude stuff is horrible, https://git.sr.ht/~q3cpma/scripts/tree/master/item/find_grep https://git.sr.ht/~q3cpma/scripts/tree/master/item/find_grep). Or you see something like https://github.com/shssoichiro/oxipng/issues/629 https://github.com/shssoichiro/oxipng/issues/629 because people don't even know how to use xargs... Feels like if someone did a RIIR on ImageMagick, it'd be able to talk with Instagram and Flickr by itself or process RAW files like Darktable. Would probably have some kind of tagging system too.
- bbkane 2y ago
  I personally appreciate the newbie friendliness and glitter, and even the "make the common case easier at the expense of composability" tradoff, though I think tlmost of these tools are still relatively composable.
- burntsushi 2y ago

thiht 2y ago

> Why would you love them just because they're in rust? That's not it. People love the new rust tools because they're great tools with sane defaults. They happen to be written in Rust most of the time and that's it so people use this to describe them.