I agree. I use grep in conjunction with find and parallel to achieve a number of features not native to grep that are built-in to these other tools.
I prefer tools designed with does one thing well philosophy. It lets me scale my knowledge. I can solve many problems with find and parallel not supported by these grep clones.
ripgrep degrades just fine to a normal grep tool. And you can use it in `find` pipelines.
> I prefer tools designed with does one thing well
This is pretty unlikely. For example, you probably use a grep tool that will also do recursive directory traversal for you. It probably even has flags for defining filters on that traversal. Why use such a tool when `find` already does recursive directory traversal for you?
"grep | head" doesn't limit the length of output lines, but "grep | cut" would.
However, ack and ripgrep's default unpiped output is grouped by file, and if you pipe the output, it doesn't do the grouped output.
The idea of "supposed to be used" is also different for ack than it is for grep. ack is specifically less of a general-use tool than grep. It's meant for searching source code. This is also why I have never said that ack is a replacement for grep.
