91–100 of 119 posts
It's sad that "bug fixes and performance improvements" has become a running joke as the explanation for software gavage, and this is even worse. "Fewer bugs and faster" is at least something most people want; "fewer bugs, faster, and random changes you didn't ask fork" is a lot less desirable.
rg is a tool that feels like magic. when in reality, like most things that feel like magic, it’s a result of exceptionally good engineering and dedication to improvement, and actually takes advantage of the incredible hardware we all use daily. It’s also smithing that’s unleashed the ability of agents to explore and reason about code faster than waiting for some sort of “lsp-like” standard we probably would’ve had to…
genuinely curious what smithing means in this context!
Earlier quoted context omitted.
Look at ag's issue tracker. There are some very critical bugs. You might be impacted by them and not even know it. As for perf, it's not hard to witness a 10x improvement that you'll actually feel. On my checkout of the Linux kernel: $ (time rg -wi '\w+(PM_RESUME|LINK_REQ)') | wc -l real 0.114 user 0.547 sys 0.543 maxmem 29 MB faults 0 444 $ (time ag -wi '\w+(PM_RESUME|LINK_REQ)') | wc -l real 0.949 user 6.618 sys 0.…
been using both for many years now, have never ran into issues or even been able to tell any difference in speed, let alone 10x what I notice unfortunatly, is that I often miss search results with rg becuase I forget I need to pass the additional -i flag. this has shaped my perception of rg - extra focus on performance, sub-optimal ux
See my other comments about perf difference. And ag has several very critical bugs. And it's unmaintained.
> or even been able to tell any difference in speed
If you only search small amounts of data, then even a naive and very slow grep is likely just fine from a perf perspective.
This week I wrote a small bash function that run ripgrep only on the files that are tracked by git: rgg() { readarray -d '' -t FILES It speeds up a lot on directories with many binary files and committed dot files. To search the dot files, -uu is needed, but that also tells ripgrep to search the binary files. On repositories with hundreds of files, the git ls-files overhead a bit large.
Can you provide a concrete example where that's faster? ripgrep should generally already be approximating `git ls-files` by respecting gitignore. Also, `-uu` tells ripgrep to not respect gitignore and to search hidden files. But ripgrep will still skip binary files. You need `-uuu` to also ignore binary files. I tried playing with your `rgg` function. First problem occurred when I tried it on a checkout the Linux ker…
It will only search tracked files. For that it can just use the index. I would expect the index to be faster than looking at the fs for listings.
Earlier quoted context omitted.
Can you provide a concrete example where that's faster? ripgrep should generally already be approximating `git ls-files` by respecting gitignore. Also, `-uu` tells ripgrep to not respect gitignore and to search hidden files. But ripgrep will still skip binary files. You need `-uuu` to also ignore binary files. I tried playing with your `rgg` function. First problem occurred when I tried it on a checkout the Linux ker…
I don't think this is the same thing as using gitignore. It will only search tracked files. For that it can just use the index. I would expect the index to be faster than looking at the fs for listings.
> ripgrep should generally already be approximating `git ls-files` by respecting gitignore.
Earlier quoted context omitted.
I don't think this is the same thing as using gitignore. It will only search tracked files. For that it can just use the index. I would expect the index to be faster than looking at the fs for listings.
I was extremely careful with my wording. Re-quoting, with added emphasis: > ripgrep should generally already be approximating `git ls-files` by respecting gitignore. See also: https://news.ycombinator.com/item?id=45629515
I've implemented gitignore aware file scanning before, and it was slower than git native operations when you only care about tracked files.
It's the speed that is the part I was speaking too, not the semantics.
I discovered and started using the silver searcher (ag) before ripgrep existed. I don't feel a strong need to switch for marginally faster search but with different command-line switches. Am I missing some killer feature here?
Fewer bugs? And perf depends on your haystack size. If you have lots of data to search, it's not hard to witness a 10x difference: https://news.ycombinator.com/item?id=45629904 As for features that ripgrep has that ag doesn't: * Much better Unicode support. (ag's is virtually non-existent.) * Pluggable preprocessors with --pre. * Jujutsu support. * ripgrep can automatically search UTF-16 data. * ripgrep has PCRE2 sup…
Earlier quoted context omitted.
I'm so happy ripgrep has a different interface to grep. I don't typically need ripgrep's better performance, I just use it because 'rg foo' does what I want 99% of the time while 'grep foo' does what I want 1% of the time.
This is pretty much flipped from my experience, so I'm curious if you could expand on this. I use grep a lot to filter command output or maybe search all my txt file notes at once when I can't remember which file contained something. I use rg rarely, one example in recent memory is searching the source code for the game Barony to try to find some lesser-known console commands or behaviors (like what all drops a parti…
But as a quick thought shortcut, I think of `ripgrep` as a search that gives similar semantics to project-wide search in a code editor or IDE. E.g., most editors will inspect a project and already ignore files that usually should be ignored (e.g., third-party dependencies, build artifacts, source control metadata like `.git/`).
Those semantics are also almost always what I want when performing a search from the command line, so `ripgrep` is what I use most of the time.