4 ms·
Your comment brings ripgrep to mind. Grep is about as ubiquitous a software tool as you can get with a very clear contract on input-output and it has absolutely
by rockemsockem 2mo ago
Your comment brings ripgrep to mind. Grep is about as ubiquitous a software tool as you can get with a very clear contract on input-output and it has absolutely stood the test of time. Then ripgrep comes along, it has the same contract as grep (with I think a few inconsistencies that were intentionally tweaked for modern use-cases...and also I'm sure a few edge-cases from its design), but is significantly faster. The fundamental contract with the user stayed the same, I'm sure some of the design changed, but fundamentally the only difference is the underlying code. And that makes such a big difference that I *always* use ripgrep over grep now as do many others.
- fragmede 2mo agoThat's a really good example. The specific detail is that node_modules isn't something I want results from while I'm grepping around.
- cben 2mo agoThat's just one half of it: Intelligent defaults + configurability of what files/dirs to skip. That part has been iterated on in prior tools like `ack` and `ag` and `git grep` for like a decade, and ripgrep was informed by that tradition. The other part is extreme optimizations, from I/O and OS aspects to CPU, both asymptotic complexity (from scratch NFA regex engine), concrete complexity (rust, SIMD) and ad-hoc opitimizations for statistically common uses like fixed strings... Then there are some "product" choices driven by performance insights, e.g. no line numbering, defaulting to non-deterministic unsorted output order — these go against most programmers' intuition for "ideal tool I'd like", but turns out the speed gains are significant and what I really like is how fast it is :-) Both usability & optimizations are described in depth by the author in https://burntsushi.net/ripgrep/ https://burntsushi.net/ripgrep/, which is one of the best perf. readings ever, highly recommended.