[TallGuyShort]

> Obviously smarter people than I disagree, but my dumdum head just feels that way.

That's absolutely not it. What you're describing is part of the UNIX philosophy: programs should do one thing and do it well, and they should function in a way that makes them very versatile and composable, etc.

And that part of the philosophy works GREAT when everything follows another part of the philosophy: everything should be based on flat text files.

But for a number of reasons, and regardless of whatever we all think of those reasons, we live in a world that has a lot of stuff that is NOT the kind of flat text file grep was made for. Binary formats, minified JS, etc. And so to make the tool more practical on a modern *nix workstation, suddenly more people want defaults that are going to work on their flat text files and transparently ignore things like .git.

It's just that you've showed up to an wildly unprincipled world armed with principles.

[saghm]

Sure, but that UNIX philosophy is what got us "grep -r" as the way to search files across an entire directory, which would then compose with stuff like xargs and parallel to be able to do things concurrently. I'd argue that ripgrep shows that that bundling together stuff sometimes does end up with a user experience that people prefer. The nuance lies in figuring out where the balance between "not enough" and "too much" lies, and so far I've yet to see a pithy statement like the UNIX philosophy encapsulate it well.

Alternately, maybe people's idea of what "one thing" is ends up being more subjective than it sounds (or at least depends on context). "Searching through my code" at least sounds like a reasonable idea of "one thing", and it's not crazy that someone might consider "don't search though the stuff that isn't my code, like my npm dependencies or my Rust build artifacts" would be part of "doing it well". Having to specify it every time would be annoying, so you might want to put it in a config file, but then if then if it ends up being identical to your gitignore, having to manually symlink it or copy it each time you modify it is annoying, so it's also not crazy to just use the gitignore by default with a way to opt out of it. Now we're just back where we started; custom .ignore files, fallback to .gitignore, and a flag for when you want to skip that.

[nrds]

I think about this at least once a week.

I first became aware of the phenomenon of an enlightened anti-UNIX bundle in ZFS; in particular how it unifies lvm, RAID, and the filesystem. While zfs isn't universally loved, it seems that each hot new filesystem that comes out now adopts this strategy as well.

While this doesn't lead to immediate enlightenment about where the balance is, it does highlight an important aspect to consider: whether the whole is more than the sum of its parts. One way openzfs is more than the sum of its parts is that it closes the RAID write hole. The next step, whether it be stabilized in openzfs or otherwise, is to merge encryption into the stack: The current state of the art is to compose block encryption with zfs on top. But a better solution would be for zfs's object layer to encrypt its blocks itself. Because the blocks are not required to have a particular disk alignment or size, the filesystem can offer authenticated encryption without losing the random-access property, as well as granular keys, thus offering some clear advantages over the UNIXy composition method.

Actually I'm not sure how strong an example ripgrep is by comparison. Could a `find` replacement do the ignore patterns just as well? OTOH, does ripgrep offer better I/O and compute parallelism than a naive xargs/parallel?

[saghm]

> Could a `find` replacement do the ignore patterns just as well? OTOH, does ripgrep offer better I/O and compute parallelism than a naive xargs/parallel?

I'm not sure if you're asking rhetorically or not, but I genuinely don't know the answers to those questions, and I'd argue that's kind of the point. Pretty much any time I've ever had to do anything non-trivial with either find or xargs, I've had to look up how to do it. The most common way I've used xargs over the years by far is piping to it as a quick and dirty way to condense whitespace to a string I get out at the end of some one-liner.

The larger point I was trying to make is that good experience out of the box" is in practice a legitimate reason that people will prefer one thing to another even if it's equivalent to some other thing you might be able to throw together manually that's just as good from a technical perspective. There's certainly power in knowing how to use composable tools, but there's also power in being able to save time to put towards other things if you care about them more, and people will have different preferences about where to strike that balance for a given tool. The more precise point I was trying to make is that "this doesn't fit the UNIX philosophy" seems like fairly weak criticism; if that's the strongest argument that can be made against ripgrep, it makes a lot of sense why it was so successful.