4 ms·

LuaJIT + C have suited me just fine for systems programming. I don't care about security, so I find it hard to care about Rust. All I care about is lessening th

LuaJIT + C have suited me just fine for systems programming. I don't care about security, so I find it hard to care about Rust. All I care about is lessening the burden on me as a programmer. I think Rust may be useful in cases like ripgrep, where you basically rewrite an existing, established tool or service used by many to be as performant and secure as possible. But other than that niche use-case, I don't think Rust will catch on in the long-term.

burntsushi 10y ago
As the author of ripgrep, I can assure you, the burden on me as the programmer was lifted quite a bit! I probably wouldn't have been able to build it otherwise. (Not because it's physically impossible, but because it would have taken too much time.) It's not like I just rewrote grep. ripgrep is built on a large number of libraries that are reusable in other applications. You can see my progress on that goal here: https://github.com/BurntSushi/ripgrep/issues/162 https://github.com/BurntSushi/ripgrep/issues/162 (And those are only the ones I wrote, nevermind all of the crates I use that have been written by others!)
- rweichler 10y ago
  Oh wow, The creator in the "flesh"! Thanks for replying to me. Hypothetical scenario: Let's say you're writing an experimental tool that doesn't exist anywhere else. You don't care about security, you don't care about speed. You just want it to exist so you can see what it does and possibly iterate on the idea if it ends up working out. Would Rust still be feasible? From my impression of it, you would need to take care of a lot of corner cases and such (which don't exist in other languages) that may slow you down in the short run. I'd imagine those corner cases would be extremely helpful in the long run if you want to squeeze some extra performance out of it (or avoid technical debt). But from the perspective of "figuring out what's possible" I feel like Rust would get in the way a lot.
  - burntsushi 10y ago
    Good question! The inherent problem with asking me that is that I've been writing Rust continuously for over 2.5 years by now. I live and breathe it. It comes as naturally to me as Go or Python does at this point (which I've been writing continuously for even longer). I will say that a comparison between Rust and C is much easier, because in the past, I've spent so much time debugging runtime errors in C with valgrind. Rust is an easy win there for me personally. I've never done much C++ so I can't provide a comparison point there. After a bit of Rust coding you get quite familiar with the workings of the borrow checker, and it becomes pretty natural to work with it. There are plenty of things you can do in C that Rust's borrow checker will forbid because it isn't smart enough to prove it safe, but there are usually straight-forward work-arounds. Sometimes the borrow checker might even help make the code a bit clearer. :-) Some of this is institutional knowledge though, so there's still a lot more documentation work left to be done! To bring this back to earth: Rust won't replace those ~100 line Python scripts that I sometimes write for quick data munging. The other important bit of context is that before I started with Rust, I had already had quite a bit of experience with C, Standard ML and Haskell. This meant that the only truly new thing I had to cope with in Rust was the borrow checker, so it might have been easier for me to digest everything than it might have been for most.
    - rweichler 10y ago
      Thanks for the insight! I may give Rust another shot at some point. Interoperating it with Lua may be fun.
Retra 10y ago
I learned Rust in a couple of weeks, and I'm writing a game in it right now. It's a pleasurable experience, and far outside that niche. "I can't learn it so nobody will use it" is such a silly thing to think.

burntsushi 10y ago

As the author of ripgrep, I can assure you, the burden on me as the programmer was lifted quite a bit! I probably wouldn't have been able to build it otherwise. (Not because it's physically impossible, but because it would have taken too much time.) It's not like I just rewrote grep. ripgrep is built on a large number of libraries that are reusable in other applications. You can see my progress on that goal here: https://github.com/BurntSushi/ripgrep/issues/162 https://github.com/BurntSushi/ripgrep/issues/162 (And those are only the ones I wrote, nevermind all of the crates I use that have been written by others!)

rweichler 10y ago
Oh wow, The creator in the "flesh"! Thanks for replying to me. Hypothetical scenario: Let's say you're writing an experimental tool that doesn't exist anywhere else. You don't care about security, you don't care about speed. You just want it to exist so you can see what it does and possibly iterate on the idea if it ends up working out. Would Rust still be feasible? From my impression of it, you would need to take care of a lot of corner cases and such (which don't exist in other languages) that may slow you down in the short run. I'd imagine those corner cases would be extremely helpful in the long run if you want to squeeze some extra performance out of it (or avoid technical debt). But from the perspective of "figuring out what's possible" I feel like Rust would get in the way a lot.
- burntsushi 10y ago
  Good question! The inherent problem with asking me that is that I've been writing Rust continuously for over 2.5 years by now. I live and breathe it. It comes as naturally to me as Go or Python does at this point (which I've been writing continuously for even longer). I will say that a comparison between Rust and C is much easier, because in the past, I've spent so much time debugging runtime errors in C with valgrind. Rust is an easy win there for me personally. I've never done much C++ so I can't provide a comparison point there. After a bit of Rust coding you get quite familiar with the workings of the borrow checker, and it becomes pretty natural to work with it. There are plenty of things you can do in C that Rust's borrow checker will forbid because it isn't smart enough to prove it safe, but there are usually straight-forward work-arounds. Sometimes the borrow checker might even help make the code a bit clearer. :-) Some of this is institutional knowledge though, so there's still a lot more documentation work left to be done! To bring this back to earth: Rust won't replace those ~100 line Python scripts that I sometimes write for quick data munging. The other important bit of context is that before I started with Rust, I had already had quite a bit of experience with C, Standard ML and Haskell. This meant that the only truly new thing I had to cope with in Rust was the borrow checker, so it might have been easier for me to digest everything than it might have been for most.
  - rweichler 10y ago
    Thanks for the insight! I may give Rust another shot at some point. Interoperating it with Lua may be fun.

Retra 10y ago

I learned Rust in a couple of weeks, and I'm writing a game in it right now. It's a pleasurable experience, and far outside that niche. "I can't learn it so nobody will use it" is such a silly thing to think.