4 ms·

Meta comment: “<doing something>… with Rust” feels like a HN meme to me. I know nothing about Rust, but I’ve noticed that there’s a top post on HN every day th

Meta comment: “<doing something>… with Rust” feels like a HN meme to me. I know nothing about Rust, but I’ve noticed that there’s a top post on HN every day that followed this format.

timeon 4y ago
> followed this format And comments like yours are following one as well.
- ryantgtg 4y ago
  As is yours!
smcl 4y ago
I'm not a Rust developer, but it seems to me that there are very real benefits to using the language. So I think the reason there are so many "I did $task in Rust!" - where $task is something usually accomplished in C, the current lingua franca of lower-level systems programming - is that people are genuinely excited to share that it really is looking possible that Rust can be used in place of C. So it's a bit of a meme, sure, but there is a good reason for it :)
- ryantgtg 4y ago
  Yeah, without knowing much about Rust, I’ve decided from these types of posts that I should gravitate toward “app I use but now it’s in Rust.” I use plenty of Rust programs simply because people seem excited about it.
  - smcl 4y ago
    Yeah that's one genre of these posts - someone sharing their experience (re)writing *nix utils like cd, ls, grep etc in Rust. But as a project I think it's unrealistic to expect they'll supplant those utilities with an identical Rust-based one, there's often not much to be gained for the risk of potentially breaking a bunch of important stuff in your system by introducing a bit of an unknown quantity, and the effort to do so with any level of quality (and then maintain it) would be pretty massive. However another genre is more interesting, to me at least - utilising existing interfaces to extend software people already use without having to make them throw out what currently works and take the risk of replacing it with a recently implemented version. In this case someone implemented a Python module in Rust, in others entire Linux device drivers have been implemented in Rust. Lower-level programming in embedded systems seems like a good application too, but I don't know how many architectures Rust can target and is officially supported on. So to summarise, the two genres[0] I've identified are, roughly: - I did a RIIR[1] of 50% of grep's functionality for fun - Here is how you can accomplish a common task in C using Rust instead As I said, not a Rust dev and frankly I'm quite intimidated by all the rants people had about fighting with "The Borrow Checker" which sounds like a ferocious Elden Ring boss. But I am tempted by the way it allows safe (or safer) software to be written. [0] - both are valid, and more exist but these are two common ones that came up [1] - RIIR = "Rewrite It In Rust", which was a bit of a meme for a while as a bunch of devs got excited about Rust and launched projects of varying completeness reimplementing things.
    - jeroenhd 4y ago
      > As I said, not a Rust dev and frankly I'm quite intimidated by all the rants people had about fighting with "The Borrow Checker" which sounds like a ferocious Elden Ring boss. But I am tempted by the way it allows safe (or safer) software to be written. In my experience, those "fighting" the borrow checker are often novices misunderstanding the language model or lacking the experience necessary to effectively use it, or extremely advanced programmers running into compiler limitations and bugs. In most Rust code there's very little fighting the borrow checker. Compare it to people saying they're fighting the compiler or fighting the interpreter when they try to multiply a string by an array and only errors come out, or trying to reassign a const value and cursing at the compiler for getting in their way. The error messages are often unhelpful and unclear (though I have to give Clang and Rust that their error messages are quite good in these days) but the core "fight" is trying to do something that doesn't make sense within the context of the programming language. For Rust, there are additional limitations on top of what your average JS/C#/Java/Python programmer will be used to. These limitations are often also present in C (you can't just share memory between threads willy-nilly, or pass around freed pointers!) where they're classified as undefined behaviour, hopefully with a warning in the console, but in Rust you must deal with the error that's been detected. The borrow checker is an extra constraint that's present in many modern C++ code bases as well, though the compiler lacks proper analysis support in many areas. It takes some getting used to memory ownership and the limitations and possibilities associated with it, but in many cases listening to and understanding the borrow checker will give you much better code (more correct code but also often clearer code) than ignoring the warnings like you would in C++. For most programming languages, a beginner needs to learn 1) installing/calling the tooling 2) the core language syntax 3) the special magic features of the language and 4) how to distribute the compiled code. With Rust there's an intermediate step between 2 and 3, the borrow checker, which beginners tend to underestimate or dismiss (I certainly did) despite the warnings in any guide. It's not especially complicated, but it's an extra step other language might lack. I recommend giving learning Rust a go. Don't be like me, don't skip the uninteresting parts of the Rust Book (https://rust-book.cs.brown.edu/ https://rust-book.cs.brown.edu/, chapter 4 is what I'm referring to), you'll only find yourself getting more frustrated. Chapter 17 (fearless conspiracy) is where I fell in love with the language, but to get through it I had to go back and actually read about ownership.
tmtvl 4y ago
To be fair though, there are also posts every so often showing "xyz library in a single C header." It gets some of the love it deserves.

Meta comment: “<doing something>… with Rust” feels like a HN meme to me. I know nothing about Rust, but I’ve noticed that there’s a top post on HN every day that followed this format.

timeon 4y ago

> followed this format And comments like yours are following one as well.

ryantgtg 4y ago
As is yours!

smcl 4y ago

I'm not a Rust developer, but it seems to me that there are very real benefits to using the language. So I think the reason there are so many "I did $task in Rust!" - where $task is something usually accomplished in C, the current lingua franca of lower-level systems programming - is that people are genuinely excited to share that it really is looking possible that Rust can be used in place of C. So it's a bit of a meme, sure, but there is a good reason for it :)

ryantgtg 4y ago
Yeah, without knowing much about Rust, I’ve decided from these types of posts that I should gravitate toward “app I use but now it’s in Rust.” I use plenty of Rust programs simply because people seem excited about it.
- smcl 4y ago
  Yeah that's one genre of these posts - someone sharing their experience (re)writing *nix utils like cd, ls, grep etc in Rust. But as a project I think it's unrealistic to expect they'll supplant those utilities with an identical Rust-based one, there's often not much to be gained for the risk of potentially breaking a bunch of important stuff in your system by introducing a bit of an unknown quantity, and the effort to do so with any level of quality (and then maintain it) would be pretty massive. However another genre is more interesting, to me at least - utilising existing interfaces to extend software people already use without having to make them throw out what currently works and take the risk of replacing it with a recently implemented version. In this case someone implemented a Python module in Rust, in others entire Linux device drivers have been implemented in Rust. Lower-level programming in embedded systems seems like a good application too, but I don't know how many architectures Rust can target and is officially supported on. So to summarise, the two genres[0] I've identified are, roughly: - I did a RIIR[1] of 50% of grep's functionality for fun - Here is how you can accomplish a common task in C using Rust instead As I said, not a Rust dev and frankly I'm quite intimidated by all the rants people had about fighting with "The Borrow Checker" which sounds like a ferocious Elden Ring boss. But I am tempted by the way it allows safe (or safer) software to be written. [0] - both are valid, and more exist but these are two common ones that came up [1] - RIIR = "Rewrite It In Rust", which was a bit of a meme for a while as a bunch of devs got excited about Rust and launched projects of varying completeness reimplementing things.
  - jeroenhd 4y ago
    > As I said, not a Rust dev and frankly I'm quite intimidated by all the rants people had about fighting with "The Borrow Checker" which sounds like a ferocious Elden Ring boss. But I am tempted by the way it allows safe (or safer) software to be written. In my experience, those "fighting" the borrow checker are often novices misunderstanding the language model or lacking the experience necessary to effectively use it, or extremely advanced programmers running into compiler limitations and bugs. In most Rust code there's very little fighting the borrow checker. Compare it to people saying they're fighting the compiler or fighting the interpreter when they try to multiply a string by an array and only errors come out, or trying to reassign a const value and cursing at the compiler for getting in their way. The error messages are often unhelpful and unclear (though I have to give Clang and Rust that their error messages are quite good in these days) but the core "fight" is trying to do something that doesn't make sense within the context of the programming language. For Rust, there are additional limitations on top of what your average JS/C#/Java/Python programmer will be used to. These limitations are often also present in C (you can't just share memory between threads willy-nilly, or pass around freed pointers!) where they're classified as undefined behaviour, hopefully with a warning in the console, but in Rust you must deal with the error that's been detected. The borrow checker is an extra constraint that's present in many modern C++ code bases as well, though the compiler lacks proper analysis support in many areas. It takes some getting used to memory ownership and the limitations and possibilities associated with it, but in many cases listening to and understanding the borrow checker will give you much better code (more correct code but also often clearer code) than ignoring the warnings like you would in C++. For most programming languages, a beginner needs to learn 1) installing/calling the tooling 2) the core language syntax 3) the special magic features of the language and 4) how to distribute the compiled code. With Rust there's an intermediate step between 2 and 3, the borrow checker, which beginners tend to underestimate or dismiss (I certainly did) despite the warnings in any guide. It's not especially complicated, but it's an extra step other language might lack. I recommend giving learning Rust a go. Don't be like me, don't skip the uninteresting parts of the Rust Book (https://rust-book.cs.brown.edu/ https://rust-book.cs.brown.edu/, chapter 4 is what I'm referring to), you'll only find yourself getting more frustrated. Chapter 17 (fearless conspiracy) is where I fell in love with the language, but to get through it I had to go back and actually read about ownership.

tmtvl 4y ago

To be fair though, there are also posts every so often showing "xyz library in a single C header." It gets some of the love it deserves.