ripgrep VS ugrep

ripgrep GitHub Fast alternative to grep

I didn't call ripgrep a replacement. Other people do. Because it does actually replace their usage of grep.

https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#can...

> The maintainer also has been pretty rude to me about this on HN.

This is AFAIK the only other interaction we've had: https://news.ycombinator.com/item?id=41051587

> but it's still crazy to think people won't be caught off guard by this behavior

Straw-manning is also crazy. :-) People have and will absolutely be caught off guard by the behavior. On the flip side, as I said 9 months ago, ripgrep's default behavior is easily one of the most cited positive features of ripgrep aside from its performance.

The other crazy thing here is... you don't have to use ripgrep! It is very specifically intended as a departure from traditional grep behavior. Because if you want traditional grep behavior, then you can just use grep. Hence why ripgrep's binary name is not `grep`, unlike many other implementations of POSIX grep.

> Its name is literally indicating it's a grep replacement.

I also tried to correct this 9 months ago too. See also: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...

For anyone else following along at home, if you want ripgrep to search the same files that GNU grep searches, then do `rg -uuu`. Or, if you don't want ripgrep to respect your gitignores but ignore hidden and binary files, then do `rg -u`.

When you think ripgrep (rg), you probably think "fast regex search tool."

I'm sure you can get creative. :-) You can set an environment variable to control the encoding, expose a flag or any one of a number of other things to control the encoding.

You've also continued to ignore my most substantive rebuttal: that a specific example where ripgrep is not compatible with grep or doesn't behave the same doesn't mean it can't be used in shell pipelines. Literally nothing you've said has invalidated anything I've said. All you're doing is finding things that some implementations of grep can do that ripgrep (intentionally) cannot do in exactly the same way. But that's fine, because ripgrep was never, isn't and will never be compatible with grep: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...

So if you need grep compatibility get a fucking clue and just use grep.

> Rust applications are sometimes (often?) slower than comparable C applications

Could you cite some examples? There are plenty of counter-examples

- ripgrep is 5-10x faster than grep (https://github.com/BurntSushi/ripgrep/blob/962d47e6a1208cf21...)

- Memory-safe implementations of PNG (png, zune-png, wuffs) now dramatically outperform memory-unsafe ones (libpng, spng, stb_image) when decoding images. (https://www.reddit.com/r/rust/comments/1ha7uyi/memorysafe_pn...)

- I don't consider the benchmarks game a worthwhile comparison because they're only writing assembly, but Rust and C are comparable in speed (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...)

- Advent of Code - I came across Rust codebases which solved all of AoC 2024 in under 1 millisecond (almost fully assembly), and also ordinary, idiomatic code in under 100 milliseconds. I don't recall anyone ever posting a C codebase with perf measurements, but I could have missed this.

I'm surprised by the "often", but I'd be interested in any cases where C outperforms Rust. Please share if you've found any.

ripgrep

The original comment said nothing about modifying servers or AWS engineers installing random shit. That was you. I responded to "moving binaries around," and you started yapping about change management. Two totally different things. Like obviously if you have a locked down environment, then only install what you need. But this is not what the original poster was referring to specifically.

ripgrep even specifically calls out this exact use case right in its README: https://github.com/BurntSushi/ripgrep/?tab=readme-ov-file#wh...

> You need a portable and ubiquitous tool. While ripgrep works on Windows, macOS and Linux, it is not ubiquitous and it does not conform to any standard such as POSIX. The best tool for this job is good old grep.

So, you presume too much friendo. Now, go away.

I switched from from ripgrep to ugrep and never looked back. It's just as fast, but also comes with fuzzy matching (which is super useful), a TUI (useful for code reviews), and can also search in PDFs, archives, etc.

The optional Google search syntax also very convenient.

https://ugrep.com

Installation and user guide: ugrep.com (no ads, no cookies, just plain HTML in a GitHub page)

Not heard of ugrep? Read the wiki on GitHub.

These ripgrep announcements are getting a bit old, don't you think? Ripgrep hasn't improved or added new features since 2016. There are other fast alternatives with a lot more features, like ugrep and qgrep for example. Ugrep has fuzzy regex pattern search, archive search (even nested archives!), Boolean search queries like Google, interactive query TUI, hexdumps, and is compatible with GNU grep (ripgrep is not).

It's the first time I hear about the ugrep. Would be nice to compare it with ripgrep, since both provide benchmark tables listing their tool at the top :D. For my everyday use speed doesn't matter much, as well as interactive mode seems useless (YMMV). So I'm staying with ripgrep for now.