rg is harder to type with one hand because it uses the same finger twice. :)
Ripgrep – A new command line search tool
21–30 of 219 posts
Re: Ripgrep – A new command line search tool
#22Rust is really staring to be seen in the wild now.
I agree, and I'm already using both ripgrep and rust-parallel ( https://github.com/mmstick/parallel , a gnu-parallel replacement which should probably get another name ). I am really happy to see Rust apps actually been written -- Rust programmers seem to be actually trying to replace the existing code lying around, instead of just insulting it and telling us how much better the world would be if we used their langua…
Well Burntsushi, the author is quite famous and level headed programmer who has written in both Go and Rust. He is exception to what you describe of Rust programmers who are still not much changed.
Re: Ripgrep – A new command line search tool
#23Thanks for the detailed comparisons and writeup. I find this simple wrapper around grep(1) very fast and useful: http://www.pixelbeat.org/scripts/findrepo
Thanks for the kind words! Note that the key thing that `findrepo` doesn't support is respecting your .gitignore files. For example, in the Rust ecosystem, we often have a `target` directory in our projects that contains a lot of stuff we probably don't want to search. In fact, running `cargo new` will add that directory to your `.gitignore` automatically! Tools like The Silver Searcher and ripgrep will ignore that d…
Yes ignoring .gitignore contents is a very useful feature.
That could be added quite easily to findrepo though would probably have to be an opt as it is often useful to search intermediate build files etc. that aren't checked in. Whereas `git grep` handles the other use case of only searching checked in files.
Interesting info wrt efficient unicode processing for \w and -i.
cheers
Re: Ripgrep – A new command line search tool
#24Earlier quoted context omitted.
I agree, and I'm already using both ripgrep and rust-parallel ( https://github.com/mmstick/parallel , a gnu-parallel replacement which should probably get another name ). I am really happy to see Rust apps actually been written -- Rust programmers seem to be actually trying to replace the existing code lying around, instead of just insulting it and telling us how much better the world would be if we used their langua…
Honestly, for a certain kind of developer—I haven't fingerpointed exactly which kind—writing Rust code is dangerously addictive. There's some combination of aggressive type checking, tooling, and expressiveness that just hits a sweet spot in my brain. Rust fills roughly the same niche in my brain as old-school C++, except it also lets me do some rudimentary functional stuff, there are virtually no footguns, and the C…
Well in the interests of making contraversal statements, that's now two Rust programs I plan on using day-to-day, and zero for Haskell, Scala, and I'm sure a few other languages I'm not remembering.
Re: Ripgrep – A new command line search tool
#25Earlier quoted context omitted.
I'm not terribly familiar with Rust's story on ARM, but I do know there are people working on cross compilation. I'll see if I can hook it up to the CI later today. Certainly, there's nothing in ripgrep itself that should prevent it from working on ARM.
I cross compile my home automation sever that I wrote in Rust to ARM. It should work.
I'll be doing that soon! Care to share your code? or explain what exactly you're doing with it?
Re: Ripgrep – A new command line search tool
#26rg is harder to type with one hand because it uses the same finger twice. :)
But 'grep' doesn't?
Re: Ripgrep – A new command line search tool
#27I'm never sure whether or not I should adopt these fancy new command line tools that come out. I get them on my muscle memory and then all of a sudden I ssh into a machine that doesn't have any of these and I'm screwed...
Re: Ripgrep – A new command line search tool
#28rg is harder to type with one hand because it uses the same finger twice. :)
lol
Re: Ripgrep – A new command line search tool
#29Meh, yet another grep tool.... wait, by burntsushi! Whenever I hear of someone wanting to improve grep I think of the classic ridiculous fish piece[0]. But when I saw that this one was by the author of rust's regex tools, which I know from a previous post on here, are quite sophisticated, I perked up.
Also, the tool aside, this blog post should be held up as the gold standard of what gets posted to hacker news: detailed, technical, interesting.
Thanks for your hard work! Looking forward to taking this for a spin.
[0] http://ridiculousfish.com/blog/posts/old-age-and-treachery.h...
Re: Ripgrep – A new command line search tool
#30It would be interesting to benchmark how much mmap hurts when operating in a non-parallel mode.
I think a lot of the residual love for mmap is because it actually did give decent results back when single core machines were the norm. However, once your program becomes multithreaded it imposes a lot of hidden synchronization costs, especially on munmap().
The fastest option might well be to use mmap sometimes but have a collection of single-thread processes instead of a single multi-threaded one so that their VM maps aren't shared. However, this significantly complicates the work-sharing and output-merging stages. If you want to keep all the benefits you'd need a shared-memory area and do manual allocation inside it for all common data which would be a lot of work.
It might also be that mmap is a loss these days even for single-threaded... I don't know.
Side note: when I last looked at this problem (on Solaris, 20ish years ago) one trick I used when mmap'ing was to skip the "madvise(MADV_SEQUENTIAL)" if the file size was below some threshold. If the file was small enough to be completely be prefetched from disk it had no effect and was just a wasted syscall. On larger files it seemed to help, though.