4 ms·

Weird question for you: how much of ripgrep's awesomeness is you/product focus vs. the power of rust? To put it another way, do you think you could've written

by dilap 7y ago

Weird question for you: how much of ripgrep's awesomeness is you/product focus vs. the power of rust? To put it another way, do you think you could've written ripgrep in another language? In C? In C++? In Go?

burntsushi 7y ago
I think Rust is probably a force multiplier here. The same program, IMO, would be harder to maintain in a language like C or C++. Although of course there are alternatives to ripgrep written in C or C++, so I'm not sure how compelling of an argument that is. But the force multiplier doesn't just need to make me more productive. Rust makes it pretty natural to factor things into libraries, and developing ripgrep over the years has caused me to produce many of them. Those in turn have been reused by other tooling, including rustc and Cargo themselves. That is something you don't often see in the C or C++ world. As for Go, I don't know. The garbage collector seems likely to be a problem. Ben Boyter wrote about working on a similarish tool in Go and problems with the GC: https://boyter.org/posts/sloc-cloc-code-performance/ https://boyter.org/posts/sloc-cloc-code-performance/ At the very least, such a tool in Go would probably require writing your own regex engine if you want to get comparable performance. (You can see how similar tools in Go, such as pt and sift, fall off a performance cliff as soon as you lean too heavily on the regex engine.) Or at the very least, contribute back to Go's standard library and make `regexp` faster. Whether it can match the speed of a Rust/C/C++ regex engine, I don't know. It's an open question I think.
- dilap 7y ago
  Thanks for the thoughtful response! My own experience w/ Rust is limited to just kicking the tires implementing my favorite toy problem, but it was incredibly positive -- my solution ended up faster than my previous best (in C++) while also having extremely-straightforward, clean code. (Something that particularly blew my mind was crossbeam_channel being (arguably) nicer than Go's built-in channels, and being able to spread work over threads w/ zero possibility of races -- that's some fuckin' cool shit.) That experience, combined w/ observation of tools like fd and ripgrep, have convinced me that rust is actually unlocking a higher level of quality for software, at least in practice, if not in theory. Your answer has not disabused me of the perception! :-) > Although of course there are alternatives to ripgrep written in C or C++, so I'm not sure how compelling of an argument that is. But they're not as good as ripgrep ;-)
  - burntsushi 7y ago
    > But they're not as good as ripgrep ;-) I would naturally agree, but my users make that argument far better than I can. :-)

by dilap 7y ago

burntsushi 7y ago

I think Rust is probably a force multiplier here. The same program, IMO, would be harder to maintain in a language like C or C++. Although of course there are alternatives to ripgrep written in C or C++, so I'm not sure how compelling of an argument that is. But the force multiplier doesn't just need to make me more productive. Rust makes it pretty natural to factor things into libraries, and developing ripgrep over the years has caused me to produce many of them. Those in turn have been reused by other tooling, including rustc and Cargo themselves. That is something you don't often see in the C or C++ world. As for Go, I don't know. The garbage collector seems likely to be a problem. Ben Boyter wrote about working on a similarish tool in Go and problems with the GC: https://boyter.org/posts/sloc-cloc-code-performance/ https://boyter.org/posts/sloc-cloc-code-performance/ At the very least, such a tool in Go would probably require writing your own regex engine if you want to get comparable performance. (You can see how similar tools in Go, such as pt and sift, fall off a performance cliff as soon as you lean too heavily on the regex engine.) Or at the very least, contribute back to Go's standard library and make `regexp` faster. Whether it can match the speed of a Rust/C/C++ regex engine, I don't know. It's an open question I think.

dilap 7y ago
Thanks for the thoughtful response! My own experience w/ Rust is limited to just kicking the tires implementing my favorite toy problem, but it was incredibly positive -- my solution ended up faster than my previous best (in C++) while also having extremely-straightforward, clean code. (Something that particularly blew my mind was crossbeam_channel being (arguably) nicer than Go's built-in channels, and being able to spread work over threads w/ zero possibility of races -- that's some fuckin' cool shit.) That experience, combined w/ observation of tools like fd and ripgrep, have convinced me that rust is actually unlocking a higher level of quality for software, at least in practice, if not in theory. Your answer has not disabused me of the perception! :-) > Although of course there are alternatives to ripgrep written in C or C++, so I'm not sure how compelling of an argument that is. But they're not as good as ripgrep ;-)
- burntsushi 7y ago
  > But they're not as good as ripgrep ;-) I would naturally agree, but my users make that argument far better than I can. :-)