4 ms·

It’s not just memory safety, it’s also hackability. Idk how I would go about adding a feature to ls (both GNU and BSD). I have a concrete idea of how I would go

It’s not just memory safety, it’s also hackability. Idk how I would go about adding a feature to ls (both GNU and BSD). I have a concrete idea of how I would go about adding a feature to the Rust implementation.

jchw 2y ago
That doesn't sound very compelling: C is still a much more popular language than Rust and a lot simpler too. I realize the latter is somewhat subjective, but it's blatant enough that I'm willing to assert it confidently. If you want to know how to add a feature to ls in GNU coreutils, you don't have to look very far. The whole program is in src/ls.c. It's pretty large due to the amount of options, but it's pretty simple code all things considered. If you look at a program with less switches, like mkdir, it's even easier. https://github.com/coreutils/coreutils/blob/master/src/mkdir.c https://github.com/coreutils/coreutils/blob/master/src/mkdir... So what about FreeBSD? Well, not only does it have an official GitHub mirror, but it even accepts "simple" pull requests, apparently. And the implementation of ls is a bit more approachable, since BSD utilities typically don't have as much functionality. https://github.com/freebsd/freebsd-src/blob/main/bin/ls/ls.c https://github.com/freebsd/freebsd-src/blob/main/bin/ls/ls.c I don't think Rust is going to make things significantly more accessible. It does indeed draw people in and maybe make them less fearful versus C, but in practice a lot of the reason why contributing to these large projects is scary is nothing to do with the language and more to do with the arduous requirements of any project that is as complicated and widely used as they are. For example, does Rust actually make kernel development more accessible? Maybe not: > Despite more novice developers being attracted by Rust to the kernel community, we have found their commits are mainly for constructing Rust-relevant toolchains as well as Rust crates alone; they do not, however, take part in kernel code development. By contrast, 5 out of 6 investigated drivers (as seen in Table 5) are mainly contributed by authors from the Linux community. This implies a disconnection between the young and the seasoned developers, and that the bar of kernel programming is not lowered by Rust language. https://www.usenix.org/conference/atc24/presentation/li-hongyu https://www.usenix.org/conference/atc24/presentation/li-hong... So if you want to add a feature to ls, maybe you shouldn't wait for operating systems to switch to Rust alternatives. But when you think about it, it is not surprising that adding a feature to ls is not easy. I mean, you really wouldn't want new features being added to utilities like ls without a ton of care and thought put in, and that is true no matter what language the utility is written in. The difficulty of contributing to some projects has very, very little to do with the actual process of writing code.
- adamnemecek 2y ago
  > Despite more novice developers being attracted by Rust to the kernel community, we have found their commits are mainly for constructing Rust-relevant toolchains as well as Rust crates alone; Is this surprising? The tooling is what needs fixing right now. Rust has been in the kernel for what a year? What are you expecting?
  - jchw 2y ago
    Oh sure, but for anyone hoping that a glut of new Linux contributors are just around the bend once the Rust tooling is in place might be suffering from unwarranted optimism. Judging by mailing list discussions, it's looking like Rust in the Linux kernel is just as complicated as C in the Linux kernel, and it won't really be a revolution so much as an incremental step. I believe that many kernel developers will probably adopt Rust because it offers them better facilities, but I don't think most Rust developers will suddenly take up kernel programming.
- tialaramex 2y ago
  "Simpler" is part of the problem. The "simplicity" is delivered by keeping more in the programmer's head and not writing it down in the C source code. But if you're not the original programmer (or you have since forgotten) that's much worse. Trivial example would be the benefits of a richer type system: You have a TCP socket, a file descriptor, and a non-negative counter In C that's an int, another int, an unsigned int In Rust that's TcpStream, OwnedFd, usize The C is simpler, there are only two types and they're both just integers. But of course in reality the more complicated Rust types model what's actually going on, these are not just integers, we shouldn't do arithmetic on an OwnedFd or a TcpStream, and we can't use a usize when we needed a TcpStream, they aren't the same kind of thing. In C that knowledge lives in your head as the programmer instead. And I disagree in practice too, as a very experienced (decades) C programmer and a relatively novice (less than 5 years) Rust programmer I am much more confident contributing to a Rust project.
  - jchw 2y ago
    To be honest, Rust having opaque handles is a pretty unimpressive demonstration of its power. If that's the main thing that code had to benefit from Rust, it would absolutely not be worth a massive new toolchain with increased memory requirements and longer compile times. Obviously, programming language design hasn't stood still in the intervening years since C was created, but C had a lot of momentum and we don't just do massive rewrites for small incremental gains. IMO the only real reason why Rust has been compelling and stands out from most other options is the borrow checker. That's the thing that is truly compelling and that people have been enduring great pains for. However, it's asymmetrical; not all code is going to have very much to gain from the borrow checker, at which point any modern systems programming language and some older ones are similarly compelling. (Note that I'm not suggesting there isn't still benefits to having the guarantees of the borrow checker, especially if you really need memory safety guarantees... but many people don't necessarily, and some that do need even stronger guarantees like formal proofs.) As far as opaque handles go, you could easily accomplish that with a subset of C++, or even with C (with an asterisk, but one that would not hinder a project like coreutils from doing so.) When talking about stuff like this we're not even really talking about C, but more coding standards that were prevalent with old UNIX and UNIX-like code. And sure, improving that is net gain, but it has little to do with the unique merits of Rust. Outside of handles, the integer type situation in C is worse than Rust or really any modern programming language, but at least most modern code will cling fairly strongly to <stdint.h> types instead. P.S.: I speak with relatively similar experience on both fronts, but I can't say the same about being particularly more confident contributing to Rust projects. It's not that it's particularly low, but 1. I don't find too many opportunities and 2. I have never found contributing to C/C++ projects to be that terrible, and I still do so occasionally.

jchw 2y ago

That doesn't sound very compelling: C is still a much more popular language than Rust and a lot simpler too. I realize the latter is somewhat subjective, but it's blatant enough that I'm willing to assert it confidently. If you want to know how to add a feature to ls in GNU coreutils, you don't have to look very far. The whole program is in src/ls.c. It's pretty large due to the amount of options, but it's pretty simple code all things considered. If you look at a program with less switches, like mkdir, it's even easier. https://github.com/coreutils/coreutils/blob/master/src/mkdir.c https://github.com/coreutils/coreutils/blob/master/src/mkdir... So what about FreeBSD? Well, not only does it have an official GitHub mirror, but it even accepts "simple" pull requests, apparently. And the implementation of ls is a bit more approachable, since BSD utilities typically don't have as much functionality. https://github.com/freebsd/freebsd-src/blob/main/bin/ls/ls.c https://github.com/freebsd/freebsd-src/blob/main/bin/ls/ls.c I don't think Rust is going to make things significantly more accessible. It does indeed draw people in and maybe make them less fearful versus C, but in practice a lot of the reason why contributing to these large projects is scary is nothing to do with the language and more to do with the arduous requirements of any project that is as complicated and widely used as they are. For example, does Rust actually make kernel development more accessible? Maybe not: > Despite more novice developers being attracted by Rust to the kernel community, we have found their commits are mainly for constructing Rust-relevant toolchains as well as Rust crates alone; they do not, however, take part in kernel code development. By contrast, 5 out of 6 investigated drivers (as seen in Table 5) are mainly contributed by authors from the Linux community. This implies a disconnection between the young and the seasoned developers, and that the bar of kernel programming is not lowered by Rust language. https://www.usenix.org/conference/atc24/presentation/li-hongyu https://www.usenix.org/conference/atc24/presentation/li-hong... So if you want to add a feature to ls, maybe you shouldn't wait for operating systems to switch to Rust alternatives. But when you think about it, it is not surprising that adding a feature to ls is not easy. I mean, you really wouldn't want new features being added to utilities like ls without a ton of care and thought put in, and that is true no matter what language the utility is written in. The difficulty of contributing to some projects has very, very little to do with the actual process of writing code.

adamnemecek 2y ago
> Despite more novice developers being attracted by Rust to the kernel community, we have found their commits are mainly for constructing Rust-relevant toolchains as well as Rust crates alone; Is this surprising? The tooling is what needs fixing right now. Rust has been in the kernel for what a year? What are you expecting?
- jchw 2y ago
  Oh sure, but for anyone hoping that a glut of new Linux contributors are just around the bend once the Rust tooling is in place might be suffering from unwarranted optimism. Judging by mailing list discussions, it's looking like Rust in the Linux kernel is just as complicated as C in the Linux kernel, and it won't really be a revolution so much as an incremental step. I believe that many kernel developers will probably adopt Rust because it offers them better facilities, but I don't think most Rust developers will suddenly take up kernel programming.
tialaramex 2y ago
"Simpler" is part of the problem. The "simplicity" is delivered by keeping more in the programmer's head and not writing it down in the C source code. But if you're not the original programmer (or you have since forgotten) that's much worse. Trivial example would be the benefits of a richer type system: You have a TCP socket, a file descriptor, and a non-negative counter In C that's an int, another int, an unsigned int In Rust that's TcpStream, OwnedFd, usize The C is simpler, there are only two types and they're both just integers. But of course in reality the more complicated Rust types model what's actually going on, these are not just integers, we shouldn't do arithmetic on an OwnedFd or a TcpStream, and we can't use a usize when we needed a TcpStream, they aren't the same kind of thing. In C that knowledge lives in your head as the programmer instead. And I disagree in practice too, as a very experienced (decades) C programmer and a relatively novice (less than 5 years) Rust programmer I am much more confident contributing to a Rust project.
- jchw 2y ago
  To be honest, Rust having opaque handles is a pretty unimpressive demonstration of its power. If that's the main thing that code had to benefit from Rust, it would absolutely not be worth a massive new toolchain with increased memory requirements and longer compile times. Obviously, programming language design hasn't stood still in the intervening years since C was created, but C had a lot of momentum and we don't just do massive rewrites for small incremental gains. IMO the only real reason why Rust has been compelling and stands out from most other options is the borrow checker. That's the thing that is truly compelling and that people have been enduring great pains for. However, it's asymmetrical; not all code is going to have very much to gain from the borrow checker, at which point any modern systems programming language and some older ones are similarly compelling. (Note that I'm not suggesting there isn't still benefits to having the guarantees of the borrow checker, especially if you really need memory safety guarantees... but many people don't necessarily, and some that do need even stronger guarantees like formal proofs.) As far as opaque handles go, you could easily accomplish that with a subset of C++, or even with C (with an asterisk, but one that would not hinder a project like coreutils from doing so.) When talking about stuff like this we're not even really talking about C, but more coding standards that were prevalent with old UNIX and UNIX-like code. And sure, improving that is net gain, but it has little to do with the unique merits of Rust. Outside of handles, the integer type situation in C is worse than Rust or really any modern programming language, but at least most modern code will cling fairly strongly to <stdint.h> types instead. P.S.: I speak with relatively similar experience on both fronts, but I can't say the same about being particularly more confident contributing to Rust projects. It's not that it's particularly low, but 1. I don't find too many opportunities and 2. I have never found contributing to C/C++ projects to be that terrible, and I still do so occasionally.