6 ms·

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.

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

yudlejoza 6y ago
I'm trolling because there is no doubt in the mind of Rust fanboys that if ripgrep was a feature-for-feature replica of grep, in some parallel hypothetical universe, it would for sure have less code-size complexity. Got it.
- saagarjha 6y ago
  Hacker News is not a place for you to troll.
- burntsushi 6y ago
  ripgrep author here. No, you're trolling because you're being disingenuous and unnecessarily inflammatory. Your LOC counting, in particular, gratuitously misses the mark for a number of reasons. Firstly, as others have pointed out, the features in GNU grep and ripgrep are radically different. GNU grep, for example, doesn't have anything that the `ignore` crate provides. So on this point alone, a simple LOC comparison falls flat. For example, does more lines of code imply that code complexity is higher? Not necessarily. Try reading and understanding the code itself. Obviously I'm biased, but I think folks would have an easier time with ripgrep than with GNU grep. Secondly, ripgrep does a lot more than GNU grep does in order to make more searches faster. This ranges from parallelism, to differing search strategies (mmap vs standard read calls) to pattern analysis for better literal optimizations and more involved SIMD algorithms and better performance in the face of Unicode. (In addition to supporting a lot more of Unicode than GNU grep does.) Making programs run faster often leads to greater code complexity. Such a phenomenon, ironically, is easy to observe when comparing GNU tools with other coreutils implementations from BSD or busybox. Thirdly, the way in which you counted lines is weirdly arbitrary. For example, GNU grep uses a lot of code from gnulib, including but not limited to, an entire regex engine. (It used to be part of GNU grep proper, so if you had done this analysis a few years ago, your LOC count would be at least double than what you came up with. Which supports my previous point: GNU grep's special lazy DFA internal regex engine only exists for performance reasons.) Fourthly, I made a decision to make a lot of ripgrep's internals generic over both the regex engine and the printer. This was to make it possible for others to use those libraries, but also to make it easier to support plugging other regex engines into ripgrep. The official ripgrep distribution, for example, comes with both Rust's regex engine and PCRE2. But it goes beyond that. Someone even maintains a fork of ripgrep[1] that uses Hyperscan[2] to make it faster in some cases. The fact that this is even plausible to do is only because much of ripgrep's core is, in fact, generic. Making things generic tends to require more code and more complexity. I made this trade off intentionally. Fifthly, your LOC counts include a ton of tests for ripgrep, where as your GNU grep LOC count presumably does not. For example, about half the LOC in the `printer` crate are tests. And that's just at a library level. Does GNU grep even have library level tests at all? A cursory glance suggests it does not. Sixthly, in the course of developing ripgrep, I made a conscious decision to contribute back to the Rust library ecosystem. As a result, several of ripgrep's libraries are now used in Cargo and rustc itself, among many other tools. GNU grep has no such goal beyond the GNU project and their gnulib itself. Writing more tightly coupled application level code would make the code much tighter. (Which you can observe for yourself by looking at the evolution of ripgrep. It started off with a lot more tightly coupled application level code.) There are probably more reasons why your comparison falls flat, but this is what I could come up with quickly before going to bed. In particular, the choice of programming language is but one factor in overall code complexity. Design goals and other such things arguably have even more of an impact. Thus, your analysis is shallow, and the lack of self-awareness of this fact combined with your inflammatory marks and seeming certainty of your position are why you are a troll. [1] - https://sr.ht/~pierrenn/ripgrep/ https://sr.ht/~pierrenn/ripgrep/ [2] - https://github.com/intel/hyperscan https://github.com/intel/hyperscan
  - xiphias2 6y ago
    While this was an interesting read, the troll won because he made you spend lots of energy. There’s a reason for the saying ,,don’t feed the troll’’. You can do so much better things with your time :)
    - burntsushi 6y ago
      It took me about ten minutes to write that. Sometimes trolls need to be called out. And sometimes, lame myths espoused by trolls need to be deconstructed. I've been on discussion forums since my childhood years. I'm well aware of my opportunity costs, thank you very much. :-)

yudlejoza 6y ago

I'm trolling because there is no doubt in the mind of Rust fanboys that if ripgrep was a feature-for-feature replica of grep, in some parallel hypothetical universe, it would for sure have less code-size complexity. Got it.

saagarjha 6y ago
Hacker News is not a place for you to troll.
burntsushi 6y ago
ripgrep author here. No, you're trolling because you're being disingenuous and unnecessarily inflammatory. Your LOC counting, in particular, gratuitously misses the mark for a number of reasons. Firstly, as others have pointed out, the features in GNU grep and ripgrep are radically different. GNU grep, for example, doesn't have anything that the `ignore` crate provides. So on this point alone, a simple LOC comparison falls flat. For example, does more lines of code imply that code complexity is higher? Not necessarily. Try reading and understanding the code itself. Obviously I'm biased, but I think folks would have an easier time with ripgrep than with GNU grep. Secondly, ripgrep does a lot more than GNU grep does in order to make more searches faster. This ranges from parallelism, to differing search strategies (mmap vs standard read calls) to pattern analysis for better literal optimizations and more involved SIMD algorithms and better performance in the face of Unicode. (In addition to supporting a lot more of Unicode than GNU grep does.) Making programs run faster often leads to greater code complexity. Such a phenomenon, ironically, is easy to observe when comparing GNU tools with other coreutils implementations from BSD or busybox. Thirdly, the way in which you counted lines is weirdly arbitrary. For example, GNU grep uses a lot of code from gnulib, including but not limited to, an entire regex engine. (It used to be part of GNU grep proper, so if you had done this analysis a few years ago, your LOC count would be at least double than what you came up with. Which supports my previous point: GNU grep's special lazy DFA internal regex engine only exists for performance reasons.) Fourthly, I made a decision to make a lot of ripgrep's internals generic over both the regex engine and the printer. This was to make it possible for others to use those libraries, but also to make it easier to support plugging other regex engines into ripgrep. The official ripgrep distribution, for example, comes with both Rust's regex engine and PCRE2. But it goes beyond that. Someone even maintains a fork of ripgrep[1] that uses Hyperscan[2] to make it faster in some cases. The fact that this is even plausible to do is only because much of ripgrep's core is, in fact, generic. Making things generic tends to require more code and more complexity. I made this trade off intentionally. Fifthly, your LOC counts include a ton of tests for ripgrep, where as your GNU grep LOC count presumably does not. For example, about half the LOC in the `printer` crate are tests. And that's just at a library level. Does GNU grep even have library level tests at all? A cursory glance suggests it does not. Sixthly, in the course of developing ripgrep, I made a conscious decision to contribute back to the Rust library ecosystem. As a result, several of ripgrep's libraries are now used in Cargo and rustc itself, among many other tools. GNU grep has no such goal beyond the GNU project and their gnulib itself. Writing more tightly coupled application level code would make the code much tighter. (Which you can observe for yourself by looking at the evolution of ripgrep. It started off with a lot more tightly coupled application level code.) There are probably more reasons why your comparison falls flat, but this is what I could come up with quickly before going to bed. In particular, the choice of programming language is but one factor in overall code complexity. Design goals and other such things arguably have even more of an impact. Thus, your analysis is shallow, and the lack of self-awareness of this fact combined with your inflammatory marks and seeming certainty of your position are why you are a troll. [1] - https://sr.ht/~pierrenn/ripgrep/ https://sr.ht/~pierrenn/ripgrep/ [2] - https://github.com/intel/hyperscan https://github.com/intel/hyperscan
- xiphias2 6y ago
  While this was an interesting read, the troll won because he made you spend lots of energy. There’s a reason for the saying ,,don’t feed the troll’’. You can do so much better things with your time :)
  - burntsushi 6y ago
    It took me about ten minutes to write that. Sometimes trolls need to be called out. And sometimes, lame myths espoused by trolls need to be deconstructed. I've been on discussion forums since my childhood years. I'm well aware of my opportunity costs, thank you very much. :-)