4 ms·

> OK, so you phrased your criticism very narrowly toward "lots of these Rust CLI tools," but in actuality, your criticism applies way more broadly than that. O

> OK, so you phrased your criticism very narrowly toward "lots of these Rust CLI tools," but in actuality, your criticism applies way more broadly than that. Obviously. The topic was Rust CLI tools, that's why my post focused on them. Indeed, my criticism is broader. > Likely to just about all of GNU's tooling, for example. And probably BSD's and busybox's tooling too. Even busybox isn't above implementing POSIX+some, and AFAIK none of them provide a strict "POSIX only" mode. This isn't about POSIX or not POSIX, this is about introducing yet another pure convenience feature for something that can easily be achieved with other accompanying (guaranteed to be on the concerned platform) tools. POSIX doesn't create features anyway, it's about describing things that have already become standard; the Austin Group bug tracker is quite explicit about this. > No... it doesn't? ripgrep being compatible with the Unix philosophy is not the same as it being POSIX compatible. Well, just a question of interpretation of "Unix-like goodness". UNIX is both a philosophy and a portability standard (since POSIX == SUSv4). And as I said, doing one thing and doing it well is another facet of that philosophy; finding files != searching in them. > And besides, I don't know of any grep that has such a mode. How do you know you aren't using a grep flag that isn't available in other grep implementations? Compatibility != strict rejection of anything else, quite obviously. > Nope, I don't. I've been a vim (now neovim) user for decades. And neovim even uses ripgrep by default over grep if it's installed. Which is why I said vim instead of neovim (even if neovim is clearly better). ------ I think you misunderstand my position because I like a bit of snark: compromising on the "do one thing" part of the UNIX philosophy isn't necessarily something horrible, but it's not an imaginary issue either. I could give other examples (like how the pretty clean xsv became https://github.com/dathere/qsv https://github.com/dathere/qsv) but it really doesn't matter because I think it's more of a popular CLI "apps" thing than Rust alone, even if there's community overlap.

burntsushi 2y ago
I can no longer see any coherent point you're trying to make. My point is that you are treating an ideal ("do one thing and doing it well") as an end instead of a means. Moreover, you are treating it as if there is any actual choice in the matter. In reality, the tooling most of us use on the command line violates the Unix philosophy in some way or another. So the question is not "should I adhere to the Unix philosophy?" but "what makes a good user experience?"
- BoingBoomTschak 2y ago
  I don't see why my point is that hard to see: the "do one thing" part of the UNIX philosophy is a good ideal to aim for, even if often ignored in favour of a more convenient kitchen sink approach. I then just mentioned that a good majority of these useful Rust tools (I really like hyperfine and oxipng, for example) don't seem to care much about it. Some example of that idea I use every day is https://codemadness.org/sfeed-simple-feed-parser.html https://codemadness.org/sfeed-simple-feed-parser.html, where feed parsing, serialization and visualization are completely separated in small orthogonal binaries with very few options. It could have been one fat "sfeed" or something like its newsboat instead. (shilling it a bit more there: https://world-playground-deceit.net/blog/2024/10/sfeed-setup.html https://world-playground-deceit.net/blog/2024/10/sfeed-setup...)
- sgarland 2y ago
  I’ve also been guilty of insisting on this, even when, as you point out, most tooling doesn’t strictly follow it anyway. I think it’s an overreaction from being irritated at seeing app after app fall to “now including AI,” or just pivoting for new features because it wasn’t making money fast enough. FWIW, I’ve been using *nix for about 25 years, and had zero problems adapting to ripgrep. You kept -i and -v, which honestly covers 90% of common usage.
  - burntsushi 2y ago
    Sorry for the late reply. I just wanted to say that I don't think AI has anything to do with this. I've been seeing this sort of complaining, goal post shifting and confusing means with ends for probably decades now. I mean, AI was around then too, but not like it is today, which is what I assume you meant. Even when I release ripgrep ~9 years ago, AI wasn't what it was today, and I saw the same sort of complaints. I don't usually like doing this, but if I had to step out of my wheelhouse and guesstimate, I think it's probably just some form of nostalgia reasoning. People remember the "simpler" times and just want to have it again. But of course, the "simpler" times are less a reflection of reality and more a reflection of your perception of the world. IMO anyway. (I have the same sort of inclination, but I try to recognize it for what it is: personal bias. Others seem unable to do this and mistake this personal bias for objective reality.)

burntsushi 2y ago

I can no longer see any coherent point you're trying to make. My point is that you are treating an ideal ("do one thing and doing it well") as an end instead of a means. Moreover, you are treating it as if there is any actual choice in the matter. In reality, the tooling most of us use on the command line violates the Unix philosophy in some way or another. So the question is not "should I adhere to the Unix philosophy?" but "what makes a good user experience?"

BoingBoomTschak 2y ago
I don't see why my point is that hard to see: the "do one thing" part of the UNIX philosophy is a good ideal to aim for, even if often ignored in favour of a more convenient kitchen sink approach. I then just mentioned that a good majority of these useful Rust tools (I really like hyperfine and oxipng, for example) don't seem to care much about it. Some example of that idea I use every day is https://codemadness.org/sfeed-simple-feed-parser.html https://codemadness.org/sfeed-simple-feed-parser.html, where feed parsing, serialization and visualization are completely separated in small orthogonal binaries with very few options. It could have been one fat "sfeed" or something like its newsboat instead. (shilling it a bit more there: https://world-playground-deceit.net/blog/2024/10/sfeed-setup.html https://world-playground-deceit.net/blog/2024/10/sfeed-setup...)
sgarland 2y ago
I’ve also been guilty of insisting on this, even when, as you point out, most tooling doesn’t strictly follow it anyway. I think it’s an overreaction from being irritated at seeing app after app fall to “now including AI,” or just pivoting for new features because it wasn’t making money fast enough. FWIW, I’ve been using *nix for about 25 years, and had zero problems adapting to ripgrep. You kept -i and -v, which honestly covers 90% of common usage.
- burntsushi 2y ago
  Sorry for the late reply. I just wanted to say that I don't think AI has anything to do with this. I've been seeing this sort of complaining, goal post shifting and confusing means with ends for probably decades now. I mean, AI was around then too, but not like it is today, which is what I assume you meant. Even when I release ripgrep ~9 years ago, AI wasn't what it was today, and I saw the same sort of complaints. I don't usually like doing this, but if I had to step out of my wheelhouse and guesstimate, I think it's probably just some form of nostalgia reasoning. People remember the "simpler" times and just want to have it again. But of course, the "simpler" times are less a reflection of reality and more a reflection of your perception of the world. IMO anyway. (I have the same sort of inclination, but I try to recognize it for what it is: personal bias. Others seem unable to do this and mistake this personal bias for objective reality.)