Why would you love them just because they're in rust?
I'd like to praise the author of this fd for not having "Rust" all over the web page or in the HN link, actually.
The Rust inquisition would get far less pushback if instead of threatening people that god will kill a kitten every time you use a non-kosher programming language, they'd promote software that improves (even opinionated improves, like this fd) on existing tools instead of having its main feature "but it's written in Rust!".
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 my mind that it will fly
ps: to show i'm not in full fanboy mode, i'm often surprised that fzf, brilliant and performant tool, is written in go, but i know it's not rust :)
... 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.
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.
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
While you’re out here complaining, the Rust community has built a truly impressive array of improved, human-focused command line tools (rg, bat, fd, hyperfine, delta, eza, and on and on) and a bunch of best-in-class libraries for building tools (regex comes to mind).
For example, ripgrep shouldn't merge find and grep (actually, I use a personal wrapper around `find ... -exec grep ... {} +` because my only beef with this is that find's syntax to exclude stuff is horrible, https://git.sr.ht/~q3cpma/scripts/tree/master/item/find_grep). Or you see something like https://github.com/shssoichiro/oxipng/issues/629 because people don't even know how to use xargs...
Feels like if someone did a RIIR on ImageMagick, it'd be able to talk with Instagram and Flickr by itself or process RAW files like Darktable. Would probably have some kind of tagging system too.
GNU grep discards the Unix philosophy in all sorts of places too. Like, why does it even bother with a -r flag in the first place? Did people back then not know how to use xargs either? I mean, POSIX knew not to include it[1], so what gives?
What's actually happening here is that what matters is the user experience, and the Unix philosophy is a means, not an end, to improve the user experience. It's a heuristic. A rule of thumb to enable composition. But it doesn't replace good judgment. Sometimes you want a little more Unix and sometimes you want a little less.
Besides, you can drop ripgrep into a shell pipeline just like you would grep. All that Unix-y goodness is still there.
[1]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/g...
Who ever claimed that GNU was a proponent of the UNIX philosophy? Certainly not me.
> What's actually happening here is that what matters is the user experience, and the Unix philosophy is a means, not an end, to improve the user experience
Yes and no. The expression "user experience" implies that all users are the same and benefit from the same philosophy of software interface design.
> Besides, you can drop ripgrep into a shell pipeline just like you would grep. All that Unix-y goodness is still there.
The "Unix-y goodness" isn't only defined by what it can do, but also what it can't do. I don't want to turn this into a suckless rant, so I won't. Also, not having a mode giving it POSIX grep compatibility really flies in the face of that claim: I want my scripts to work on BSD, MacOS and even Solaris/AIX without having to install stuff.
------
I know I may sound very smug but believe me when I say that I really like some of these utils and the care put into them (and I know you're the author of ripgrep) and that I'm no UNIX OpenBSD user (Plan 9 exists for a reason, and I favor CL over C/Go any time of the day). But I really see them as optimizing for/targeting the VSCode/Zed crowd, instead of the vim/emacs one, if you know what I mean.
Which is fine, but now your position is more "old man yelling at clouds" than it is something specific about the Rust tools. (And to be clear, I'm not above yelling at clouds now and then.)
> Also, not having a mode giving it POSIX grep compatibility really flies in the face of that claim
No... it doesn't? ripgrep being compatible with the Unix philosophy is not the same as it being POSIX compatible. I didn't say you could use ripgrep in any place you could use grep in a drop-in compatible way. I said you could use it in shell pipelines. As in, it inter-operates with other tooling in a Unix-y way.
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?
> But I really see them as optimizing for/targeting the VSCode/Zed crowd, instead of the vim/emacs one, if you know what I mean.
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.
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) 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.
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?"
Some example of that idea I use every day is 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...)
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.
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.)
Nothing was specific to GNU in that comment. `-r` is available in BSD grep too. You are being needlessly pedantic and avoiding the actual points being made while doing so.
> Yes and no. The expression "user experience" implies that all users are the same and benefit from the same philosophy of software interface design.
No, it doesn’t. You have literally made that up out of whole cloth, but it isn’t how anyone else I’m aware of defines “user experience”.
As BurntSushi pointed out, ripgrep is even designed to adapt to different means of use: as a standalone command, as a utility in a pipe, and others. Improving the usability for one use-case isn’t necessarily at the cost of others.
> I want my scripts to work on BSD, MacOS and even Solaris/AIX without having to install stuff.
So your very reasonable desire to stick with POSIX for shell scripts… means we shouldn’t ever make new tools? I’m genuinely failing to understand your point here.
In fact, having a “grep compatibility flag” would very literally be the opposite of the UNIX philosophy you’re holding up elsewhere. ripgrep isn’t grep. It isn’t trying to be grep. It’s something new and different and (in some use-cases) better. The old thing still exists and if you want to use it for whatever reason… just do that?
Where's the actual point in "others do it too"?
> No, it doesn’t. You have literally made that up out of whole cloth, but it isn’t how anyone else I’m aware of defines “user experience”.
That's not a question of definition, but of use in an English sentence. If you say "this is good for user experience", you implicitly group all users together. I say some users prefer tools that do only one thing. ripgrep itself acknowledges that "despite initially not wanting to add every feature under the sun to ripgrep, over time, ripgrep has grown support for most features found in other file searching tools". And that's fine! But not for everybody.
> As BurntSushi pointed out, ripgrep is even designed to adapt to different means of use: as a standalone command, as a utility in a pipe, and others. Improving the usability for one use-case isn’t necessarily at the cost of others.
If I like the "finding files with auto filtering" part of ripgrep, how can I use it to feed another grep or even another tool? If it had been designed with the aforementioned philosophy, it would have been "ripfind" + "ripgrep" and maybe a "ripfg" pretty interface on top.
> So your very reasonable desire to stick with POSIX for shell scripts… means we shouldn’t ever make new tools? I’m genuinely failing to understand your point here.
> In fact, having a “grep compatibility flag” would very literally be the opposite of the UNIX philosophy you’re holding up
See my other reply: I love new tools, but "UNIX-like goodness" is also about portability (as in SUS), not just the philosophy. More of a misunderstanding than anything else, really.
A flag would be impossible, but introspection based on argv[0] (like Busybox) wouldn't be that far-fetched. But yeah, clearly ripgrep isn't trying to replace only grep, that was a mistake on my part.
As an addendum, the "UNIX philosophy" had a lot of crap parts (e.g. bytes as universal interchange format) and UNIX itself is a very poor implementation of said philosophy (after all, g/re/p itself is pointless porcelain over (s)ed, heh), I'm not sure discussing it seriously without specifying which part (like "do one thing") is very productive.
`rg --files`
Is your mind blown yet?
> is also about portability
Except for Windows.
> Except for Windows.
Of course POSIX portability doesn't apply to OSes which intentionally ignore it. I think I have another flame appreciating guy on the other side of the conversation =)
At this point it sounds like you're making a purely aesthetic/cultural judgment, rather than a technical one. ripgrep works just fine with emacs; I have "C-c p s r" bound to "run ripgrep in current project" and use it almost every day.
Both are “must haves” as far as I’m concerned.
That's not it. People love the new rust tools because they're great tools with sane defaults. They happen to be written in Rust most of the time and that's it so people use this to describe them.
Of course, then we get the question, ok, why not use a program that just provides those options? But, I think all the extra functionality of tar is nice to have sitting off there in the background; I’d have to look it up if I actually wanted to use it, but it is all there in the documentation, and nicely compatible with the files produced by my memorized commands.
That is, if before there is something at /some/path but not /another/path , after running
ln /some/path /another/path
Another piece of this parallel is that (with cp and mv) you can omit naming the destination file - you often just name the directory:
cp /other/dir/foo.txt .
ln -s /other/dir/foo.txt
If the first argument isn’t an absolute path, it must be relative to the second argument, and not to pwd.
ln ./foo ./bar/baz
This is totally backwards from how other utilities behave. Which is completely understandable if you know what it’s doing under the hood. But it is counterintuitive and surprising.
Not a solution for all problems, but it works for me most of the time.
Sometimes you semantically want absolute paths (I want to symlink a thing to /bin/foo), sometimes you want relative paths (I want to symlink a thing to something in a nested directory).
I remember only two flags for tar. That's it.
tar -x
tar -c
I use it like so:
tar -c src | gzip > src.tar.gz
curl https://source.code/src.tar.gz | gunzip | tar -x
The core operations taking up only this much headspace leaves the door open to slowly start to retain all its other useful options. For example, -v, which means verbose almost everywhere, thankfully means verbose here too, so I add that when I want verbosity.
Similarly, I find it easy to retain -l which lists the contents. I do this quite often for stuff from the internet -- I don't like it when I untargz in ~/Downloads and it untargz's it in the same directory instead of doing everything inside a parent directory (preferably with the same name as the archive)
Bonus: separating out the gzip like this makes it easy to remember how to use zstd if you want to, just pipe to zstd instead! "Unix philosophy" and all that.
I agree with you about `ln`, I can never seem to remember if it's source or target that comes first.