5 ms·

> modern take What that? Why would I use these rather than the unix tools I have been pretty happy with for nearly 40 years? And which come installed on every

> modern take What that? Why would I use these rather than the unix tools I have been pretty happy with for nearly 40 years? And which come installed on every unix-like distro.

gui77aume 6y ago
I guess it means more modern implementation (rust). ripgrep is faster than grep, but there are some differences, not exactly the same flags, for example. If you use grep on big files regularly it worth a try.
rgoulter 6y ago
There are UX benefits of `rg` (or whatever alternatives) over `grep`. e.g. ignoring the .git directory by default. - Plenty of these things _can_ be done with grep, but the newer tools offer the benefits out of the box. Generally, the UX improvements involve better colouring and a more intuitive set of arguments. "installed on every unix-like distro" is an advantage if you're frequently jumping into environments without these tools installed. In that context, it's worth learning the defaults of these tools. - But in many jobs you're able to work on the same computer, and benefit from e.g. customising dotfiles, using whichever tools you want.
SubjectToChange 6y ago
I use ripgrep because it is noticeably snappier, especially for unicode. Other tools like hyperfine or fd are just more convenient. I'd have no problem replacing ls with another tool, but none of them support viewing SELinux attributes. I really don't care whether a tool is standard or not when it comes to a workstation. I have so many thinks tweaked and personalized that using a few nonstandard tools doesn't make a difference.
happymellon 6y ago
It would be better if it was written in rust, but I prefer `httpie` to `curl` because I find the syntax significantly easier to get my head around even though curl is installed on virtually every Linux distro I almost always get the syntax wrong. But if you prefer a tool, there is no reason to switch of you don't want to.
- duckerude 6y ago
  > It would be better if it was written in rust There is a project to rewrite HTTPie in Rust: https://github.com/ducaale/xh https://github.com/ducaale/xh (Disclaimer: I'm one of the developers)
  - happymellon 6y ago
    Oh wow, I will check this out! Thank you for bringing it to my attention
- stonecharioteer 6y ago
  FWIW xh is slowly catching up to httpie. Look it up, it's in rust.
bitwize 6y ago
> Why would I use these rather than the unix tools I have been pretty happy with for nearly 40 years? Because they're fearlessly written in Rust! And so ｍｏｄｅｒｎ...
Smithalicious 6y ago
Because it's New and Written In Rust
- selfhoster11 6y ago
  Ripgrep and fd could be written in Brainf*ck for all I care. The big win is the improved UX and not having to `man grep`/`man find` when I want to go beyond the two parameters I memorised.
  - Smithalicious 6y ago
    I'm half-joking. I use some of these utilities myself occasionally, and even more of them have ended up in my Emacs toolchain simply because they're faster. On the other hand, there's value in all of these ancient, ubiquitous and battle-tested utilities. You're doing yourself a disservice not learning find and grep. And I do poke fun at the "rewrite it in rust" crowd even though I think Rust itself is incredibly exciting. There's nothing as easy as reinventing existing tools in a greenfield code base. Inventing truly new things and maintaining old code are both much harder and much more valuable. Not saying that the existing tools don't need an update every now and then, but I'm not particularly impressed, despite these things being flashy.
coldtea 6y ago
Because "it's old" and "it's everywhere" also holds for things we can and/or should replace. Else you'd be using the tools they were using not 40 years before now, but 20+ years BEFORE the advent of UNIX still. Now, except for the convenience of "it's on every linux distro" which is more a theoritical convenience (since it's 2021, we have networking, package managers, provisioning, and other niceties, you can take your tools with you to a new job, or the servers you manage. Do you really want to constrain your toolset to the lowest common denominator lest you have to once in a blue moon log in some non-touchable system for some session and you wont have ripgrep there?. (And if you're not an admin but a developer that makes even less sense - you're supposed to be in far more control of your development enviromnet). The "I've used for 40 years" argument either amounts to (a) I don't want to learn something new, even if it's improved (which one can respect, but is not a general argument, as others might want to learn something new), or (b) I think the existing versions are the global maxima of such tool design, or close enough not to matter. Note that (most likely) the tools you use are already replaced versions of the old UNIX and/or POSIX tools -- namely GNU versions of those, with tons of extra functionality and flags and in several cases different behavior. Without those a system (I had the displeasure to work in some legacy unices like AIX etc that didn't have them by default, but had the legacy UNIX versions of such) feels absolutely medieval...
- goatinaboat 6y ago
  The "I've used for 40 years" argument either amounts to (a) I don't want to learn something new, even if it's improved (which one can respect, but is not a general argument, as others might want to learn something new), or (b) I think the existing versions are the global maxima of such tool design, or close enough not to matter. Because I want to write scripts with the minimal possible support overhead. That means striking a balance between the lowest common denominator, and productivity. Does (for example) ripgrep give me so much extra speed that it's worth committing to the overhead of installing it and keeping it patched up to date on thousands or tens of thousands of machines? With a dozen or more combinations of distro/version? What if the next guy has his own favourite grep replacement? What if we construct a suite of tools and all of them grep in a different way, and someone else a year or 5 years or 10 years later has to debug it? What if two or more of these tools decide that they are the one that gets to replace grep with a symlink to themselves? Having been there and done that it gets very messy, very quickly. Note I'm not saying that grep can't be improved - but I am saying that it would be better to PR those improvements into grep itself rather than creating a new and incompatible thing. Or fork grep and ensure that the improved version is fully backwards compatible.
paholg 6y ago
For the ones I've used, because they're faster and/or much more ergonomic. ripgrep and fd are both much faster and nicer to use than their traditional counterparts. bat has support for syntax highlighting in many languages, and automatically pages long output. It's really nice. I prefer the output of exa to ls. Those are the ones I've tried, and I use them all regularly. Writing a portable script, sure I'd still reach for grep. But for tools on the commandline, these are a big improvement.
nvarsj 6y ago
The only thing really worth it is ripgrep, which is substantially faster than plain grep.
selfhoster11 6y ago
1. Newbies to Unix don't come with 40 years of experience, they need to pick these tools up from scratch. When the newer tools have substantially better UX, it's a no-brainer that they would be used. I still remember being a newbie, and improving the UX (note, not dumbing-down) of our tools would go a little ways to alleviating the difficulty of navigating an unfamiliar terrain. 2. Those tools are also 40 years behind what we know we can accomplish in command line UX. They cannot afford to modernise without breaking backwards compat of the historical output text and the params, so they stay frozen. Any changes would have to come from new Unix tools written from scratch, which is what `exa`, ripgrep and `fd` are doing.

> modern take What that? Why would I use these rather than the unix tools I have been pretty happy with for nearly 40 years? And which come installed on every unix-like distro.

gui77aume 6y ago

I guess it means more modern implementation (rust). ripgrep is faster than grep, but there are some differences, not exactly the same flags, for example. If you use grep on big files regularly it worth a try.

rgoulter 6y ago

There are UX benefits of `rg` (or whatever alternatives) over `grep`. e.g. ignoring the .git directory by default. - Plenty of these things _can_ be done with grep, but the newer tools offer the benefits out of the box. Generally, the UX improvements involve better colouring and a more intuitive set of arguments. "installed on every unix-like distro" is an advantage if you're frequently jumping into environments without these tools installed. In that context, it's worth learning the defaults of these tools. - But in many jobs you're able to work on the same computer, and benefit from e.g. customising dotfiles, using whichever tools you want.

SubjectToChange 6y ago

I use ripgrep because it is noticeably snappier, especially for unicode. Other tools like hyperfine or fd are just more convenient. I'd have no problem replacing ls with another tool, but none of them support viewing SELinux attributes. I really don't care whether a tool is standard or not when it comes to a workstation. I have so many thinks tweaked and personalized that using a few nonstandard tools doesn't make a difference.

happymellon 6y ago

It would be better if it was written in rust, but I prefer `httpie` to `curl` because I find the syntax significantly easier to get my head around even though curl is installed on virtually every Linux distro I almost always get the syntax wrong. But if you prefer a tool, there is no reason to switch of you don't want to.

duckerude 6y ago
> It would be better if it was written in rust There is a project to rewrite HTTPie in Rust: https://github.com/ducaale/xh https://github.com/ducaale/xh (Disclaimer: I'm one of the developers)
- happymellon 6y ago
  Oh wow, I will check this out! Thank you for bringing it to my attention
stonecharioteer 6y ago
FWIW xh is slowly catching up to httpie. Look it up, it's in rust.

bitwize 6y ago

> Why would I use these rather than the unix tools I have been pretty happy with for nearly 40 years? Because they're fearlessly written in Rust! And so ｍｏｄｅｒｎ...

Smithalicious 6y ago

Because it's New and Written In Rust

selfhoster11 6y ago
Ripgrep and fd could be written in Brainf*ck for all I care. The big win is the improved UX and not having to `man grep`/`man find` when I want to go beyond the two parameters I memorised.
- Smithalicious 6y ago
  I'm half-joking. I use some of these utilities myself occasionally, and even more of them have ended up in my Emacs toolchain simply because they're faster. On the other hand, there's value in all of these ancient, ubiquitous and battle-tested utilities. You're doing yourself a disservice not learning find and grep. And I do poke fun at the "rewrite it in rust" crowd even though I think Rust itself is incredibly exciting. There's nothing as easy as reinventing existing tools in a greenfield code base. Inventing truly new things and maintaining old code are both much harder and much more valuable. Not saying that the existing tools don't need an update every now and then, but I'm not particularly impressed, despite these things being flashy.

coldtea 6y ago

Because "it's old" and "it's everywhere" also holds for things we can and/or should replace. Else you'd be using the tools they were using not 40 years before now, but 20+ years BEFORE the advent of UNIX still. Now, except for the convenience of "it's on every linux distro" which is more a theoritical convenience (since it's 2021, we have networking, package managers, provisioning, and other niceties, you can take your tools with you to a new job, or the servers you manage. Do you really want to constrain your toolset to the lowest common denominator lest you have to once in a blue moon log in some non-touchable system for some session and you wont have ripgrep there?. (And if you're not an admin but a developer that makes even less sense - you're supposed to be in far more control of your development enviromnet). The "I've used for 40 years" argument either amounts to (a) I don't want to learn something new, even if it's improved (which one can respect, but is not a general argument, as others might want to learn something new), or (b) I think the existing versions are the global maxima of such tool design, or close enough not to matter. Note that (most likely) the tools you use are already replaced versions of the old UNIX and/or POSIX tools -- namely GNU versions of those, with tons of extra functionality and flags and in several cases different behavior. Without those a system (I had the displeasure to work in some legacy unices like AIX etc that didn't have them by default, but had the legacy UNIX versions of such) feels absolutely medieval...

goatinaboat 6y ago
The "I've used for 40 years" argument either amounts to (a) I don't want to learn something new, even if it's improved (which one can respect, but is not a general argument, as others might want to learn something new), or (b) I think the existing versions are the global maxima of such tool design, or close enough not to matter. Because I want to write scripts with the minimal possible support overhead. That means striking a balance between the lowest common denominator, and productivity. Does (for example) ripgrep give me so much extra speed that it's worth committing to the overhead of installing it and keeping it patched up to date on thousands or tens of thousands of machines? With a dozen or more combinations of distro/version? What if the next guy has his own favourite grep replacement? What if we construct a suite of tools and all of them grep in a different way, and someone else a year or 5 years or 10 years later has to debug it? What if two or more of these tools decide that they are the one that gets to replace grep with a symlink to themselves? Having been there and done that it gets very messy, very quickly. Note I'm not saying that grep can't be improved - but I am saying that it would be better to PR those improvements into grep itself rather than creating a new and incompatible thing. Or fork grep and ensure that the improved version is fully backwards compatible.

paholg 6y ago

For the ones I've used, because they're faster and/or much more ergonomic. ripgrep and fd are both much faster and nicer to use than their traditional counterparts. bat has support for syntax highlighting in many languages, and automatically pages long output. It's really nice. I prefer the output of exa to ls. Those are the ones I've tried, and I use them all regularly. Writing a portable script, sure I'd still reach for grep. But for tools on the commandline, these are a big improvement.

nvarsj 6y ago

The only thing really worth it is ripgrep, which is substantially faster than plain grep.

selfhoster11 6y ago

1. Newbies to Unix don't come with 40 years of experience, they need to pick these tools up from scratch. When the newer tools have substantially better UX, it's a no-brainer that they would be used. I still remember being a newbie, and improving the UX (note, not dumbing-down) of our tools would go a little ways to alleviating the difficulty of navigating an unfamiliar terrain. 2. Those tools are also 40 years behind what we know we can accomplish in command line UX. They cannot afford to modernise without breaking backwards compat of the historical output text and the params, so they stay frozen. Any changes would have to come from new Unix tools written from scratch, which is what `exa`, ripgrep and `fd` are doing.