3 ms·

Maybe I’m just old fashioned but all these new command line utilities strike me as solutions in search of a problem. Standard ‘find’ works great. It finds file

by lumb63 4y ago

Maybe I’m just old fashioned but all these new command line utilities strike me as solutions in search of a problem. Standard ‘find’ works great. It finds files. It can filter by any criteria I have ever had to look for and the syntax seems very intuitive to me (maybe I am just used to it). It is flexible and powerful. I’d love to be told I’m wrong, because I feel like I’m missing something.

MichaelDickens 4y ago
'find' is slow to the point of being useless for me. It can never find the file I'm looking for before I give up waiting for it to finish running. So I'm excited if fd can provide the same functionality but run much faster.
- pphysch 4y ago
  Are you inadvertently hitting a big .git/ with every find?
burntsushi 4y ago
The "new CLI utilities" aren't solving new problems. They are solving old problems with a different user experience, driven by changes in how folks do development (particularly the scales). Notice that I said "different" UX and not "better" UX. Reasonable people can disagree about whether the newer tools have better UX as an objective fact. Many folks very rightly find it very surprising that these tools will skip over things automatically by default. What is true, however, is that there are a lot of people who do see the UX of these tools as better for them. As the author of ripgrep, I hear the same thing over and over again: ripgrep replaced their ~/bin grep wrapper with a bunch of --exclude rules that filtered out files they didn't want to search. Because if you don't do that, a simple 'grep -r' can take a really fucking long time to run if you're working on a big project. And guess what: a lot of programmers these days work on big projects. (See previous comment about changes in scale.) So you don't really have a choice: you either write a wrapper around grep so that it doesn't take forever, or you use a "smarter" tool that utilizes existing information (gitignore) to effectively do that for you. That smarter tool typically comes with other improvements, because your simple "grep wrapper" probably doesn't use all of the cores on your machine. It could, but it probably doesn't. So when you switch over, it's like fucking magic: it does what you wanted and it does it better than your wrapper. Boom. Throw away that wrapper and you're good to go. That's what I did anyway. (I had several grep wrappers before I wrote ripgrep.) Every time these tools are discussed here, people say the same thing: "I don't see the point." It's a failure of imagination to look beyond your own use cases. If all you ever work on are smaller projects, then you're never going to care about the perf difference between ripgrep and grep. ripgrep has other improvements/changes, but nearly all of them are more niche than the UX changes and the perf improvements.
- benhoyt 4y ago
  Definitely agree. I really like that ripgrep is fast, but I mainly use it for its better UX for what I do every day: search code. If ripgrep wasn't any faster than grep, but was still recursive by default and ignored .gitignore et al, it'd still be worth using for me. (In fact, I used to use "ack", which is basically ripgrep but slow. :-)
cheeze 4y ago
Call me naive/dumb/whatever, but I can't stand find's interface. Even things as simple as -depth rather than --depth bother me

by lumb63 4y ago

MichaelDickens 4y ago

'find' is slow to the point of being useless for me. It can never find the file I'm looking for before I give up waiting for it to finish running. So I'm excited if fd can provide the same functionality but run much faster.

pphysch 4y ago
Are you inadvertently hitting a big .git/ with every find?

burntsushi 4y ago

The "new CLI utilities" aren't solving new problems. They are solving old problems with a different user experience, driven by changes in how folks do development (particularly the scales). Notice that I said "different" UX and not "better" UX. Reasonable people can disagree about whether the newer tools have better UX as an objective fact. Many folks very rightly find it very surprising that these tools will skip over things automatically by default. What is true, however, is that there are a lot of people who do see the UX of these tools as better for them. As the author of ripgrep, I hear the same thing over and over again: ripgrep replaced their ~/bin grep wrapper with a bunch of --exclude rules that filtered out files they didn't want to search. Because if you don't do that, a simple 'grep -r' can take a really fucking long time to run if you're working on a big project. And guess what: a lot of programmers these days work on big projects. (See previous comment about changes in scale.) So you don't really have a choice: you either write a wrapper around grep so that it doesn't take forever, or you use a "smarter" tool that utilizes existing information (gitignore) to effectively do that for you. That smarter tool typically comes with other improvements, because your simple "grep wrapper" probably doesn't use all of the cores on your machine. It could, but it probably doesn't. So when you switch over, it's like fucking magic: it does what you wanted and it does it better than your wrapper. Boom. Throw away that wrapper and you're good to go. That's what I did anyway. (I had several grep wrappers before I wrote ripgrep.) Every time these tools are discussed here, people say the same thing: "I don't see the point." It's a failure of imagination to look beyond your own use cases. If all you ever work on are smaller projects, then you're never going to care about the perf difference between ripgrep and grep. ripgrep has other improvements/changes, but nearly all of them are more niche than the UX changes and the perf improvements.

benhoyt 4y ago
Definitely agree. I really like that ripgrep is fast, but I mainly use it for its better UX for what I do every day: search code. If ripgrep wasn't any faster than grep, but was still recursive by default and ignored .gitignore et al, it'd still be worth using for me. (In fact, I used to use "ack", which is basically ripgrep but slow. :-)

cheeze 4y ago

Call me naive/dumb/whatever, but I can't stand find's interface. Even things as simple as -depth rather than --depth bother me