6 ms·

I agree, and I'm already using both ripgrep and rust-parallel ( https://github.com/mmstick/parallel https://github.com/mmstick/parallel , a gnu-parallel replace

I agree, and I'm already using both ripgrep and rust-parallel ( https://github.com/mmstick/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 language.

ekidd 10y ago
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 CLI tooling is out of this world. And I've long since made friends with the borrow checker. So it's tempting to just spend my life cranking out Rust code as fast as I can. It's actually a problem. :-)
- CJefferson 10y ago
  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.
  - unfamiliar 10y ago
    It will only be a matter of time before someone rewrites xmonad in Rust.
    - steveklabnik 10y ago
      Negative time, actually: https://github.com/kintaro/wtftw https://github.com/kintaro/wtftw (there's an i3 inspired one as well, I forget the link)
      - awesomebob 10y ago
        Nice! I think this is the other one you were thinking of: https://github.com/tsurai/xr3wm https://github.com/tsurai/xr3wm
        FreeFull 10y ago
        There is a different one based on wlc (So it's a wayland compositor, rather than just an X11 window manager). The one you linked doesn't seem to have been updated since 2015 Edit: Here it is: https://github.com/Immington-Industries/way-cooler https://github.com/Immington-Industries/way-cooler
  - deleted 10y ago
    [deleted]
  - sitkack 10y ago
    I need an R5RS+ Scheme that is tightly integrated with Rust. High-level and fast enough, with the ability to drop down into Rust for speed.
  - livestockboy 10y ago
    Pandoc Xmonad Darcs Git-annex Although, it would be very hard to write SIMD performant code in Haskell, even its string libraries don't use any optimization tricks.
    - dgr-nn-glth 10y ago
      I was excited when I heard of it, but I thought Darcs had run into some major issues with patch theory and exponential merges. Other than it being written in Haskell, why would I use it over git?
      - livestockboy 10y ago
        Well, speed issues are currently not that noticeable (a lot of times passed since initial bumps) but I'm pretty sure some large repositories (more than millions of lines of patches) wouldn't be able to work with it. git is a whole different story compared to darcs, darcs is simpler to use, especially when merging. if it was consistently fast I'm pretty sure git wouldn't be as popular as it is. there is rust vcs https://pijul.org/ https://pijul.org/ that seems to be doing the same thing as darcs but faster. so I guess CJefferson's controversial comment stands :D
geodel 10y ago
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.
- burntsushi 10y ago
  Actually, I'm no exception at all. The Rust community (and the Go community) is full of level headed exceptional people. I love working with them!
saurik 10y ago
This would have been a lot more exciting if it were designed to actually be even slightly compatible with grep (or maybe had some core in there that was, while leaving the other UI parts he wants to change on top) and were then approaching GNU and saying "hey, this is something I've been working on: would you consider making grep the first standalone tool to move to Rust, and what would it take from me to make this happen?" as opposed to writing an article about how "I am smarter than the GNU grep people for these reasons and have built a tool named after how my tool is going to kill their tool" which almost seems to go out of its way to set up an air of competition rather than collaboration. Maybe you value pure technical chops, and the difference between "insulting it and telling us how" is much worse than "insulting it and actually writing code", but to me they both start with "insulting it" and demonstrate an almost tragic inability to work with others. For people like me, people who actually want to see a language like Rust get used en masse and entirely replace languages like C, the attitude in this blog post is extremely depressing. Even if I now we're to myself take the time to go to the GNU grep authors and try to talk to them about this, the mere existence of this blog post is going to make that slightly more taxing and slightly more of a battle for everyone involved :/. (I mean: seriously... "ripgrep"?! This developer is clearly going out of their way to be combative. What ever happened to the open source spirit of collaboration? What happened to actual communication between teams? Why do projects seem to just assume "the design decisions, or even specific implementations, or even accidental mistake of existing tools are set in stone, and so the right way to talk about changing them is to discuss competition between entire projects or at best hard forks rather than working with other people"? :/)
- steveklabnik 10y ago
  (small note, the name wasn't intended to be about killing grep, it was "rip" as in "rips through your code very quickly". Of course, intention doesn't count, etc, but just to be clear about the history.)
- sidlls 10y ago
  Is there anything about ripgrep that makes its performance uniquely fast? That is, is it not possible to achieve the same speed and correctness of results using, say, C or C++? If neither condition holds, then the use of Rust is almost purely incidental. It isn't even interesting, from that perspective. Far more interesting would be a measure of how safe the Rust code is versus equivalent-results implementations in other languages.

ekidd 10y ago

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 CLI tooling is out of this world. And I've long since made friends with the borrow checker. So it's tempting to just spend my life cranking out Rust code as fast as I can. It's actually a problem. :-)

CJefferson 10y ago
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.
- unfamiliar 10y ago
  It will only be a matter of time before someone rewrites xmonad in Rust.
  - steveklabnik 10y ago
    Negative time, actually: https://github.com/kintaro/wtftw https://github.com/kintaro/wtftw (there's an i3 inspired one as well, I forget the link)
    - awesomebob 10y ago
      Nice! I think this is the other one you were thinking of: https://github.com/tsurai/xr3wm https://github.com/tsurai/xr3wm
      - FreeFull 10y ago
        There is a different one based on wlc (So it's a wayland compositor, rather than just an X11 window manager). The one you linked doesn't seem to have been updated since 2015 Edit: Here it is: https://github.com/Immington-Industries/way-cooler https://github.com/Immington-Industries/way-cooler
- deleted 10y ago
  [deleted]
- sitkack 10y ago
  I need an R5RS+ Scheme that is tightly integrated with Rust. High-level and fast enough, with the ability to drop down into Rust for speed.
- livestockboy 10y ago
  Pandoc Xmonad Darcs Git-annex Although, it would be very hard to write SIMD performant code in Haskell, even its string libraries don't use any optimization tricks.
  - dgr-nn-glth 10y ago
    I was excited when I heard of it, but I thought Darcs had run into some major issues with patch theory and exponential merges. Other than it being written in Haskell, why would I use it over git?
    - livestockboy 10y ago
      Well, speed issues are currently not that noticeable (a lot of times passed since initial bumps) but I'm pretty sure some large repositories (more than millions of lines of patches) wouldn't be able to work with it. git is a whole different story compared to darcs, darcs is simpler to use, especially when merging. if it was consistently fast I'm pretty sure git wouldn't be as popular as it is. there is rust vcs https://pijul.org/ https://pijul.org/ that seems to be doing the same thing as darcs but faster. so I guess CJefferson's controversial comment stands :D

geodel 10y ago

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.

burntsushi 10y ago
Actually, I'm no exception at all. The Rust community (and the Go community) is full of level headed exceptional people. I love working with them!

saurik 10y ago

This would have been a lot more exciting if it were designed to actually be even slightly compatible with grep (or maybe had some core in there that was, while leaving the other UI parts he wants to change on top) and were then approaching GNU and saying "hey, this is something I've been working on: would you consider making grep the first standalone tool to move to Rust, and what would it take from me to make this happen?" as opposed to writing an article about how "I am smarter than the GNU grep people for these reasons and have built a tool named after how my tool is going to kill their tool" which almost seems to go out of its way to set up an air of competition rather than collaboration. Maybe you value pure technical chops, and the difference between "insulting it and telling us how" is much worse than "insulting it and actually writing code", but to me they both start with "insulting it" and demonstrate an almost tragic inability to work with others. For people like me, people who actually want to see a language like Rust get used en masse and entirely replace languages like C, the attitude in this blog post is extremely depressing. Even if I now we're to myself take the time to go to the GNU grep authors and try to talk to them about this, the mere existence of this blog post is going to make that slightly more taxing and slightly more of a battle for everyone involved :/. (I mean: seriously... "ripgrep"?! This developer is clearly going out of their way to be combative. What ever happened to the open source spirit of collaboration? What happened to actual communication between teams? Why do projects seem to just assume "the design decisions, or even specific implementations, or even accidental mistake of existing tools are set in stone, and so the right way to talk about changing them is to discuss competition between entire projects or at best hard forks rather than working with other people"? :/)

steveklabnik 10y ago
(small note, the name wasn't intended to be about killing grep, it was "rip" as in "rips through your code very quickly". Of course, intention doesn't count, etc, but just to be clear about the history.)
sidlls 10y ago
Is there anything about ripgrep that makes its performance uniquely fast? That is, is it not possible to achieve the same speed and correctness of results using, say, C or C++? If neither condition holds, then the use of Rust is almost purely incidental. It isn't even interesting, from that perspective. Far more interesting would be a measure of how safe the Rust code is versus equivalent-results implementations in other languages.