Yeah there's a lot of that, but grep is like using duct tape to hold something together when you really should be using screws or so. grep can do everything, but its not always the best tool for the job.
The "ack" you reference is apparently faster only in that it's easier to specify exactly which files to search or not to search, which obviously can also be done with grep, e.g. combined with 'find'.
As for grep itself, it has had many incarnations over the decades with various pluses and minuses.
The current GNU grep allows 3 kinds of regex, basic/extended/perl -- the latter being what ack supports.
Note that Perl regexes have extensions beyond regular languages that are inherently slower than the automata specified by basic regexes. Power versus speed.
E.g. grep(1): "Back-references are very slow, and may require exponential time."
For further info:
> why GNU grep is fast
> Mike Haertel mike at ducky.net
> Sat Aug 21 03:00:30 UTC 2010
> Here's a blog post from 2006 about a developer trying to "beat grep" and looking at the algorithms it uses; it goes into a little more detail about the "doesn't need to do the loop exit test at every step" optimization mentioned in this email.
The best writeup is surely by the inimitable Russ Cox, who really really explains clearly when grep as of 2007 was one of the only fast regex implementations:
Regular Expression Matching Can Be Simple And Fast [#1]
(but is slow in Java, Perl, PHP, Python, Ruby, ...)
(This is a 4 part series but IIRC part 1 has the highlights)
I'm sure that various other tools have been strongly influenced by this famous essay, and so many more things may be as fast as grep by now, but still...
P.S. one of the other high profile "ack"-like search tools would be "ag", aka "The Silver Surfer".
"The Silver Searcher is a 3-5x faster drop in replacement for ack (which itself is better than grep)."
http://beyondgrep.com/