I do not have an issue with this command, regex field separator and negative index alone makes it a good alternative over cut. And I use ripgrep too. I'm bothered by the description.
I would even suggest the command to add ability to invert the ranges, byte selection (if -c is character and not byte selection), add examples for character splitting in README, etc.
There are literally thousands of Unix tool replacements released on GitHub, and more every year.
Just off the top of my head, fex and miller are alternative cut-likes with field extraction.
Unless a new unix-tool-alike is significantly better and backwards-compatible, HN and most greybeard nixers tend toward conservatism. The old tools are usually good for 95% of use-cases anyway. There's just way too much to keep track of if you're eager to switch to any old shiny new thing.
Tools like rg offer additional features and/or save you from tediously specifying many options. This one gives you -f for free, that’s about it. Detailed comparison: https://news.ycombinator.com/edit?id=23445931
- it supports regex separators. That's a great feature to me.
- the default separator is "\s", like python's split(). Just for that I will adopt it: not having to care about tabs/spaces/mixes is a much better experience.
- it has negative indexes, again like python. Getting the last field, or the last nth field, is something common enought. I don't want to rewrite the thing with a twisted double "rev" with proper index. And I don't want to have to google it.
- plus the syntax is just must easier to remember to me. When I use cut, I always try: "echo 'foo bar baz' | cut 2", just to realize that I need to pass '-f', then I do "cut -f 2", and get stump, and google it, to then remember I need to pass the delimiter explicitly even if it's a space.
I would even suggest the command to add ability to invert the ranges, byte selection (if -c is character and not byte selection), add examples for character splitting in README, etc.