alt Hacker NewsThe future of code search is not regex – 100x faster than ripgrep
Comments
I ran across this fascinating tool a few days ago researching embedding models on hugging face.
Advertised as "ColGREP Semantic code search for your terminal and your coding agents",
I haven't put it in any harness yet but I probably should.
https://github.com/lightonai/next-plaid/tree/main/colgrep
I've also tried astgrep (also known as sg) but llms really mess up on them. I think you'd need to fine tune.
If anyone has cracked that case I'd love to hear about it
The future is lack of scrolling on mobile, and scanning getting stuck, apparently.
considering that ripgrep has marginal overhead over just reading the files to /dev/null, how exactly does this achieve 100x speedup?
I have a lot of use for something that can search ~1GB of text "instantly", but so far nothing beats rg/ag after the data has been moved into RAM.
I have open sourced the fastest code search implementation. Comprehensive SDK for both file finder and grep file search that is over 100x faster than ripgrep
I've entered "bazel" and got `shellPrefix.ts` which doesn't relate to bazel in any way.
If that's the future then I'll stay in the past with ripgrep.
It has never been ripgrep for decades for those of us on IDEs.
Is there a write up of the underlying approach? The summary on the repo mentioned SIMD, but not a whole lot else.
I don't get it how can I search anything but the file name?
ctags, GNU Global and even "ugrep -Q" would like to have a few words with you ;)
Why is it "for neovim"? Surely such a thing would be useful in many applications?
How's it work? Embed tokens and use euclidean distance or something?
Websites that don’t tell me what they’re doing are infuriating. I’m on mobile. This landing page experience is awful.
[dead]
Why do all vibecoded sites look the same? Same black on neon vibes and button styles
Where can I find the benchmark for the "20-50 times faster than ripgrep" claim from the documentation, or the "100x faster" claim from the HN submission title?
Ripgrep already has optimizations for regex which don't contain any patterns (or even just regex which contain such substrings). So "not regex" shouldn't be what makes the difference.