3 ms·
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 developme
by 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 agoDefinitely 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. :-)