Hacker News Reader

Maybe the fact that ripgrep contains more lines of code is related to the fact that it has more features, and not just about the language it's written in? https://beyondgrep.com/feature-comparison/

Also, it's kind of pointless to compare lines of code given that both projects get large amounts of their functionality from dependencies. For instance, the GNU grep repository doesn't actually contain any regex-matching code; that's all in gnulib.

EDIT: If you already knew that ripgrep had more features, and yet your immediate reaction was that you "can't take those guys and their language seriously", then your comment is straight-up trolling. Please don't do that here.

The "proper" comparison (that would still be horribly misguided) would be against the "core" crate in ripgrep. And that's only 5kloc, a lot of it from the "app.rs" (3kloc) and "args.rs" (1.2kloc) which is almost only declarative usage strings.

The "actual" code of ripgrep is accross its multiple support crates, which the community largely benefits from having since those are general enough to be almost foundational to any software.

imo, op is trolling, the old fashioned way

As a Rust developer (not really), after getting sick and tired of hearing about C everywhere, I decided to do a bit of assessment in terms of code-size complexity.

I heard of Linux, an amazing operating system kernel that beats Redox in the dust.

I have never seen Redox source code. I told myself, if I download Linux-on-C and Redox-on-Rust and find out that Linux is doing all it's doing in one-tenth the size of Redox source code, or even half the code size, I'd be quite impressed, and be willing to take C seriously.

Well guess what, I downloaded the two sources. Redox kernel source code is about 24k LoC. Linux? about 27M.

WTF.

----

In all seriousness, LoC comparisons are absolutely the worst way to compare languages, especially across projects that are completely different in scope and design.

(This was a joking reply in the style of OP's now-flagged comment, which was comparing LoC between ripgrep and grep.)

> I heard of ripgrep, an amazing twenty-first century revolution that beats grep in the dust.

So, when you heard that, you thought "LOC"? Not safety, not speed, not features, not FFI, but LOC? why?

Maybe because that's the only metric that C is better at (I jest)

I'm sure every project having it's own buffer, list, config, logging, hashmap and endianness implementation helps a lot with that :)

IIUC, minimum code size was not the top priority of the creator of ripgrep.

And Rust's claim to fame is not that it allows you to get the job done with less code. Its claim is that it allows you to get the job done, but with far fewer memory access issues, without sacrificing runtime efficiency.

Perhaps the developers had a success metric other than LOC.

You are acting as if these are the same thing. ripgrep has more features than grep and that is going to take more code. At the very least you can drop the printer and ignore crates. You are still looking at twice the code but ripgrep is doing parallel searching so it is obviously going to be more. How much more is hard to say without trying to rewrite one or the other to make this an apples-to-apples comparison.

And even if it results in 1-2x amount of code that is not the end-all metric. How quickly was this code written and how easy is it to maintain? How many bugs does it have?

I mean rust is basically a superset of C (other than having to write "unsafe" everywhere if you use a c-style), so it is hard to dismiss this as wasted noise because if it was wasted wouldn't people have written it like C line-for-line?

The amount of damage stupid and overconfident people can cause with sharp tools like C is a too high to bear risk. That’s why we instead use Java or (God forbid) JavaScript, but at the expense of speed.

Rust tries to gain back this lost speed without making it too easy for idiots to destroy everything. Such code can of course look larger and more convoluted than over decades on every corner optimized C code, but at least we’re as fast as C and much safer from ignorant people.

Making tools for "idiots" didn't really work out so far, that's how we got Cobol and Java.

From my experience, empathy works better as a design strategy.

For the record, that word has never been used to describe Rust's goals by those who work on it. The slogan of the language is "empowering everyone to build reliable and efficient software."

And for what it's worth, I think the people working on Rust are empathetic and it shows in their work. For example, he error messages given by the compiler try to hand hold you gently when you're learning the language.

For the record, how else do you call obtuse persons who proudly claim to be C programmers waving around with LOCs like a troll? :)

What's the issue with Java? It empowers teams consisting of many heterogeneous people to get work done easier and limits the scope to logical errors only.

> edit: to those who're saying ripgrep is more than grep. First, I know. Second, wouldn't it be great if someone could rewrite ripgrep in C? Now I'm really curious to find out the code-size complexity of all the ripgrep features backported to grep.

I'd be shocked if a C version measured fewer LoC without resorting to some real dark art pointer magic.

ripgrep's src/ contain both library code and unit tests. The grep source code appears to use different tests/ and src/ directories.

ripgre's source code files appear to be between 1/3 and 1/2 unit tests, in the few samples I checked. For example, https://github.com/BurntSushi/ripgrep/blob/master/crates/sea...

You know you can just ignore the Rust talk? And maybe measuring things by how many LoC they require is not the best metric.

ripgrep isn't a 1:1 rewrite of grep. It's a different program.

ripgrep does more than vanilla grep.

How is looking at LoC meaningful?