6 ms·

EDIT: It is very bit unfortunate that my general/off-topic comment is currently the most upvoted. I was not commenting on the Linux integration specifically. I'

by dgb23 4y ago

EDIT: It is very bit unfortunate that my general/off-topic comment is currently the most upvoted. I was not commenting on the Linux integration specifically. I'm a _novice and hobbyist_ when it comes to Rust. For example this comment https://news.ycombinator.com/item?id=31849071 https://news.ycombinator.com/item?id=31849071 is much more interesting and on topic. --- I want to provoke a little bit, but I'm genuinely curious about the following: I feel like the Rust ecosystem is still quite immature in a lot of areas. Just a few indicators to illustrate what I mean: - Both async/await and the question mark operator feel like rushed implementations, neither seem like the best long term solutions for Rust and are not in line with the otherwise solid foundation of the language. - Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem. - Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with. - Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making. I really like the language, I have _way_ more good things to say about it than bad things. But am I alone in feeling like this? Other modern language communities come with a philosophy that promotes stability and simplicity. Is the Rust community riding on the merits of Rust's unique value proposition, while forgetting some important fundamentals?

bragr 4y ago
I'd encourage you to go read the project docs in the kernel for this. This rust project has been ongoing for years and I believe the documentation and discussion there addresses all the issues you raise. This is not a knee jerk "fashionable" decision.
icambron 4y ago
What’s your complaint about the question mark operator?
- bonzini 4y ago
  It's not extensible (the `Try` trait is unstable) but this is being worked on, see https://github.com/rust-lang/rfcs/blob/master/text/3058-try-trait-v2.md https://github.com/rust-lang/rfcs/blob/master/text/3058-try-....
- dgb23 4y ago
  In of itself it seems like a very nice feature. However it represents something that I don't like, which is trading language surface complexity and readability for programmer convenience. It is not something that gives you more power, just something that makes code a bit easier to write. Also there was seemingly not that much push-back against the feature which makes me a bit uneasy. Not sure why that is to be honest. I don't want to start a discussion about the question mark operator specifically. That's not important to me. What I like to gauge is the general culture around the language itself and the community around it. Half devil's advocate, half uncertainty driven.
  - Fiahil 4y ago
    > However it represents something that I don't like, which is trading language surface complexity and readability for programmer convenience. In this case it's a welcomed convenience. Have you used `thiserror` and `anyhow` crates ? They may alter your judgement on that point.
  - bigbillheck 4y ago
    > It is not something that gives you more power, just something that makes code a bit easier to write. Who needs a for loop when you have while?
    - dgb23 4y ago
      For and while have different semantics. For is not just sugar for a while loop, it means something more specific and restricted than a general while.
      - 4y ago
mejutoco 4y ago
> Some projects pride themselves to not use "unsafe" code This is normal? not having unsafe code does not guarantee absence of bugs, but at least it isolates the problematic bits in the sections marked as unsafe. If you need unsafe, you can always use unsafe. Battle tested codebases like bind or openssh — and many others, independently of the language of implementation — had bugs in the past. It always helps to have extra assurances. Using safe/Unsafe is one more tool to have assurances.
Fiahil 4y ago
> - Both async/await [...] feel like rushed implementations This is a recurring comment, but I would argue that it's not "rushed" but rather "incomplete" from supporting ecosystem (like a futures library being reactor-agnostic). Async/Await is great for a couple of things, but not a silver bullet. So, apart from high-throughput network applications, (like web/app servers), you should stick to regular threads and channels. You can leverage Actor-based concurrency in your program that isn't async. > - Rust is fashionable. Because it's genuinely great ! I've been writing Rust code since 2018, and at that time "Golang" in titles would get all the hype. I get the urge to keep things as a secret underground in a true Hacker spirit. Relax : nobody is going to spoil Rust and Rust isn't going to become a new Javascript.
gspr 4y ago
While I love Rust, I think you're spot on with your concerns (apart from the questionmark operator – it's just delicious pragmatic convenience). The culture of exploding dependency trees is a recipe for disaster, especially when combined with the prevailing attitude of "use the latest version or bust".
- cmrdporcupine 4y ago
  Yeah, I've been down this road before with Java + Maven 10-15 years ago. Exploding dependency trees, DLL hell, etc. And I see it in the (admittedly mostly foreign to me) Node/NPM world. Quantities of third party dependencies with their own graphs can be trouble. At least with Maven there was a publishing/vetting process. Still, it makes dev a lot easier.
jtdowney 4y ago
> - Both async/await and the question mark operator feel like rushed implementations, neither seem like the best long term solutions for Rust and are not in line with the otherwise solid foundation of the language. I'd disagree with both of these. They may not be to your style but that doesn't make them rushed. Both features had long debates around their adoption. > - Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem. That is irrelevant to this project. You should read the rust kernel docs to see why. > - Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with. Also irrelevant. This may be a criticism of Rust but it in no way affects how rust may be adopted into linux. > - Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making. Linus is famous for doing fashionable things and forgoing technical decision making.
- ncmncm 4y ago
  In particular, Rust has every single thing that Linus famously hated about C++, and lots more in that vein, besides. Has he changed his mind about those things? Or does he not realize they are there, and that kernel code will use them?
  - tialaramex 4y ago
    Lets see your list of "every single thing that Linus famously hated about C++" When I try to make a list one of the first things I find is "any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn't come and screw up any project I'm involved with."
    - ncmncm 4y ago
nindalf 4y ago
> objective, technical decision making There have been several carefully planned iterations of the Rust for Linux effort. Every iteration has addressed some feedback from senior kernel developers including Linus Torvalds. The Rust for Linux folks then worked with the Rust project to introduce these features slowly into Rust. An example of such a change is fallible memory allocation. These iteration cycles have been happening for years. Check out the issues, especially the “wanted features and bugfixes” for each rust component (https://github.com/Rust-for-Linux/linux/issues?page=2&q=is%3Aissue+is%3Aopen https://github.com/Rust-for-Linux/linux/issues?page=2&q=is%3...) for more details into all the work that’s happened here. Throughout I have seen nothing but professionalism, courtesy and hard work from all parties involved here - the kernel devs, the Rust for Linux devs and the Rust project devs. You do them all a disservice by implying that this decision was taken without “objective, technical decision making”. > not linking with C code I would need specific examples of C code being better than the Rust equivalent but people using the Rust equivalent anyway. I can give several counter examples. Such as libgit2, a C library with Rust bindings. It is widely used in the Rust ecosystem, including by the Rust project itself instead of the nascent gitoxide project. This shows pragmatism. There are other examples of projects being rewritten in Rust but usually that’s ends up with the Rust version being very good. Such as when the maintainer of rsvg rewrote it in Rust. Look at the test suite results (https://github.com/RazrFalcon/resvg https://github.com/RazrFalcon/resvg). Or when someone wrote a text search tool (ripgrep) in pure Rust instead of using PCRE bindings. Look at the benchmarks (https://github.com/BurntSushi/ripgrep/blob/master/benchsuite/runs/2020-10-14-archlinux-frink/summary https://github.com/BurntSushi/ripgrep/blob/master/benchsuite...) - it’s faster than any competing tool on nearly all of them. If you’ve used search in VSCode, you were using ripgrep. Or when someone wrote a pure Rust crypto library rustls when OpenSSL bindings exist. I believe the results of the security audit speak for themselves (https://github.com/rustls/rustls/blob/main/audit/TLS-01-report.pdf https://github.com/rustls/rustls/blob/main/audit/TLS-01-repo...). See the comments on code quality - “Cure53 was unable to uncover any application-breaking security flaws. After spending thirty days on the scope in late May and early June of 2020, the team of auditors considered the general code quality to be exceptional and can attest to a solid impression left consistently by all scope items. Naturally, this is partially thanks to the usage of Rust as the preferred language for the entire implementation of the rustls project” These examples show that when good developers rewrite something in Rust, we all benefit from the results. If you have an example of a Rust rewrite giving worse results, and being adopted over the C bindings, that would be helpful. I can’t recall any such instance offhand. > Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem. Could you give examples? From what I’ve seen Rust library authors take care to only pull in what’s necessary. I’d be interested to see these libraries that pull in “unrelated” dependencies. Note, developing in Rust doesn’t suddenly make mediocre code great. I’m sure there’s mediocre code out there, just like there is in every single ecosystem. The question is, can you get stuff done while only sticking to high quality dependencies? I think you can. > async-await and question mark. There is a language strangeness budget each language gets to use. Use up too much of the budget and the language feels alien to newcomers. Rust already introduces new strange things like lifetimes. New syntax like the question mark and post-fix await strain the budget further. I’ll admit, it’s hard for new people. But I also think this syntax pulls it’s weight. This is subjective and reasonable people can disagree. That said, these syntax decisions are set in stone. I wouldn’t wait in the hope that they might change.
belter 4y ago
Plus the whole issue of Cargo namespace squatting... https://users.rust-lang.org/t/name-squatting-on-the-crates-io/42415 https://users.rust-lang.org/t/name-squatting-on-the-crates-i...
- mcdonje 4y ago
  If you have a good solution to rent-seeking, a great many marketplaces would benefit.
  - cyborgx7 4y ago
    Not giving out real estate on a "first come-first serve basis" but actively moderating the allotment of real estate.
    - dutchmartin 4y ago
      I’ve seen and reported those squads and the admins did properly address those.
      - account42 4y ago
        The discussion in this subthread is about https://crates.io/crates/keyboard https://crates.io/crates/keyboard which still exist as do the other obvious squatted names from the same user: https://crates.io/users/swmon https://crates.io/users/swmon
  - dgb23 4y ago
    Composite namespaces. Like "mcdonje/fourtytwo" or "com.acme/http".
- baby 4y ago
  How is that an issue?
  - sa46 4y ago
atoav 4y ago
One thing on the plus site: a tech blogger was calling out a tournament for the fastest string tokenizer in any language. I wrote a very naive Rust tokenizer in 5 minutes max and it easily won second place. First place was a highly optimized assembler code. I am not sure the assembler thing would handle UTF-8 as well as my incredibly low effort Rust solution tho. What I want to say with this is: There are real, tangible advantages to the language when some noob who would shoot himself into the leg three times while writing the C/C++ equivalent manages to write safe code that performs well while not investing a lot of time.
- sharedptr 4y ago
  This example requires seeing both submissions for C and C++ to compare on their actual speed with the Rust one though

by dgb23 4y ago

bragr 4y ago

I'd encourage you to go read the project docs in the kernel for this. This rust project has been ongoing for years and I believe the documentation and discussion there addresses all the issues you raise. This is not a knee jerk "fashionable" decision.

icambron 4y ago

What’s your complaint about the question mark operator?

bonzini 4y ago
It's not extensible (the `Try` trait is unstable) but this is being worked on, see https://github.com/rust-lang/rfcs/blob/master/text/3058-try-trait-v2.md https://github.com/rust-lang/rfcs/blob/master/text/3058-try-....
dgb23 4y ago
In of itself it seems like a very nice feature. However it represents something that I don't like, which is trading language surface complexity and readability for programmer convenience. It is not something that gives you more power, just something that makes code a bit easier to write. Also there was seemingly not that much push-back against the feature which makes me a bit uneasy. Not sure why that is to be honest. I don't want to start a discussion about the question mark operator specifically. That's not important to me. What I like to gauge is the general culture around the language itself and the community around it. Half devil's advocate, half uncertainty driven.
- Fiahil 4y ago
  > However it represents something that I don't like, which is trading language surface complexity and readability for programmer convenience. In this case it's a welcomed convenience. Have you used `thiserror` and `anyhow` crates ? They may alter your judgement on that point.
- bigbillheck 4y ago
  > It is not something that gives you more power, just something that makes code a bit easier to write. Who needs a for loop when you have while?
  - dgb23 4y ago
    For and while have different semantics. For is not just sugar for a while loop, it means something more specific and restricted than a general while.
    - 4y ago

mejutoco 4y ago

> Some projects pride themselves to not use "unsafe" code This is normal? not having unsafe code does not guarantee absence of bugs, but at least it isolates the problematic bits in the sections marked as unsafe. If you need unsafe, you can always use unsafe. Battle tested codebases like bind or openssh — and many others, independently of the language of implementation — had bugs in the past. It always helps to have extra assurances. Using safe/Unsafe is one more tool to have assurances.

Fiahil 4y ago

> - Both async/await [...] feel like rushed implementations This is a recurring comment, but I would argue that it's not "rushed" but rather "incomplete" from supporting ecosystem (like a futures library being reactor-agnostic). Async/Await is great for a couple of things, but not a silver bullet. So, apart from high-throughput network applications, (like web/app servers), you should stick to regular threads and channels. You can leverage Actor-based concurrency in your program that isn't async. > - Rust is fashionable. Because it's genuinely great ! I've been writing Rust code since 2018, and at that time "Golang" in titles would get all the hype. I get the urge to keep things as a secret underground in a true Hacker spirit. Relax : nobody is going to spoil Rust and Rust isn't going to become a new Javascript.

gspr 4y ago

While I love Rust, I think you're spot on with your concerns (apart from the questionmark operator – it's just delicious pragmatic convenience). The culture of exploding dependency trees is a recipe for disaster, especially when combined with the prevailing attitude of "use the latest version or bust".

cmrdporcupine 4y ago
Yeah, I've been down this road before with Java + Maven 10-15 years ago. Exploding dependency trees, DLL hell, etc. And I see it in the (admittedly mostly foreign to me) Node/NPM world. Quantities of third party dependencies with their own graphs can be trouble. At least with Maven there was a publishing/vetting process. Still, it makes dev a lot easier.

jtdowney 4y ago

> - Both async/await and the question mark operator feel like rushed implementations, neither seem like the best long term solutions for Rust and are not in line with the otherwise solid foundation of the language. I'd disagree with both of these. They may not be to your style but that doesn't make them rushed. Both features had long debates around their adoption. > - Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem. That is irrelevant to this project. You should read the rust kernel docs to see why. > - Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with. Also irrelevant. This may be a criticism of Rust but it in no way affects how rust may be adopted into linux. > - Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making. Linus is famous for doing fashionable things and forgoing technical decision making.

ncmncm 4y ago
In particular, Rust has every single thing that Linus famously hated about C++, and lots more in that vein, besides. Has he changed his mind about those things? Or does he not realize they are there, and that kernel code will use them?
- tialaramex 4y ago
  Lets see your list of "every single thing that Linus famously hated about C++" When I try to make a list one of the first things I find is "any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn't come and screw up any project I'm involved with."
  - ncmncm 4y ago

nindalf 4y ago

> objective, technical decision making There have been several carefully planned iterations of the Rust for Linux effort. Every iteration has addressed some feedback from senior kernel developers including Linus Torvalds. The Rust for Linux folks then worked with the Rust project to introduce these features slowly into Rust. An example of such a change is fallible memory allocation. These iteration cycles have been happening for years. Check out the issues, especially the “wanted features and bugfixes” for each rust component (https://github.com/Rust-for-Linux/linux/issues?page=2&q=is%3Aissue+is%3Aopen https://github.com/Rust-for-Linux/linux/issues?page=2&q=is%3...) for more details into all the work that’s happened here. Throughout I have seen nothing but professionalism, courtesy and hard work from all parties involved here - the kernel devs, the Rust for Linux devs and the Rust project devs. You do them all a disservice by implying that this decision was taken without “objective, technical decision making”. > not linking with C code I would need specific examples of C code being better than the Rust equivalent but people using the Rust equivalent anyway. I can give several counter examples. Such as libgit2, a C library with Rust bindings. It is widely used in the Rust ecosystem, including by the Rust project itself instead of the nascent gitoxide project. This shows pragmatism. There are other examples of projects being rewritten in Rust but usually that’s ends up with the Rust version being very good. Such as when the maintainer of rsvg rewrote it in Rust. Look at the test suite results (https://github.com/RazrFalcon/resvg https://github.com/RazrFalcon/resvg). Or when someone wrote a text search tool (ripgrep) in pure Rust instead of using PCRE bindings. Look at the benchmarks (https://github.com/BurntSushi/ripgrep/blob/master/benchsuite/runs/2020-10-14-archlinux-frink/summary https://github.com/BurntSushi/ripgrep/blob/master/benchsuite...) - it’s faster than any competing tool on nearly all of them. If you’ve used search in VSCode, you were using ripgrep. Or when someone wrote a pure Rust crypto library rustls when OpenSSL bindings exist. I believe the results of the security audit speak for themselves (https://github.com/rustls/rustls/blob/main/audit/TLS-01-report.pdf https://github.com/rustls/rustls/blob/main/audit/TLS-01-repo...). See the comments on code quality - “Cure53 was unable to uncover any application-breaking security flaws. After spending thirty days on the scope in late May and early June of 2020, the team of auditors considered the general code quality to be exceptional and can attest to a solid impression left consistently by all scope items. Naturally, this is partially thanks to the usage of Rust as the preferred language for the entire implementation of the rustls project” These examples show that when good developers rewrite something in Rust, we all benefit from the results. If you have an example of a Rust rewrite giving worse results, and being adopted over the C bindings, that would be helpful. I can’t recall any such instance offhand. > Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem. Could you give examples? From what I’ve seen Rust library authors take care to only pull in what’s necessary. I’d be interested to see these libraries that pull in “unrelated” dependencies. Note, developing in Rust doesn’t suddenly make mediocre code great. I’m sure there’s mediocre code out there, just like there is in every single ecosystem. The question is, can you get stuff done while only sticking to high quality dependencies? I think you can. > async-await and question mark. There is a language strangeness budget each language gets to use. Use up too much of the budget and the language feels alien to newcomers. Rust already introduces new strange things like lifetimes. New syntax like the question mark and post-fix await strain the budget further. I’ll admit, it’s hard for new people. But I also think this syntax pulls it’s weight. This is subjective and reasonable people can disagree. That said, these syntax decisions are set in stone. I wouldn’t wait in the hope that they might change.

belter 4y ago

Plus the whole issue of Cargo namespace squatting... https://users.rust-lang.org/t/name-squatting-on-the-crates-io/42415 https://users.rust-lang.org/t/name-squatting-on-the-crates-i...

mcdonje 4y ago
If you have a good solution to rent-seeking, a great many marketplaces would benefit.
- cyborgx7 4y ago
  Not giving out real estate on a "first come-first serve basis" but actively moderating the allotment of real estate.
  - dutchmartin 4y ago
    I’ve seen and reported those squads and the admins did properly address those.
    - account42 4y ago
      The discussion in this subthread is about https://crates.io/crates/keyboard https://crates.io/crates/keyboard which still exist as do the other obvious squatted names from the same user: https://crates.io/users/swmon https://crates.io/users/swmon
- dgb23 4y ago
  Composite namespaces. Like "mcdonje/fourtytwo" or "com.acme/http".
baby 4y ago
How is that an issue?
- sa46 4y ago

atoav 4y ago

One thing on the plus site: a tech blogger was calling out a tournament for the fastest string tokenizer in any language. I wrote a very naive Rust tokenizer in 5 minutes max and it easily won second place. First place was a highly optimized assembler code. I am not sure the assembler thing would handle UTF-8 as well as my incredibly low effort Rust solution tho. What I want to say with this is: There are real, tangible advantages to the language when some noob who would shoot himself into the leg three times while writing the C/C++ equivalent manages to write safe code that performs well while not investing a lot of time.

sharedptr 4y ago
This example requires seeing both submissions for C and C++ to compare on their actual speed with the Rust one though