3 ms·

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 m

• 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