9 ms·

I have a number of negative stereotypes associated with Rust and Rust programmers that I am trying to set aside right now and just look at this from a technical

by daptaq 4y ago

I have a number of negative stereotypes associated with Rust and Rust programmers that I am trying to set aside right now and just look at this from a technical perspective. Has the Rust-portability situation been addressed? Or will this change restrict the number of platforms the Linux kernel will be usable on? Assuming that is the case (I remember reading that GCC will acquire Rust support), what will the advantages be? I would guess stability might improve due to more static analysis, but what about performance? Build-time? And will this have any effect on Rust?

dgs_sgd 4y ago
What are the negative stereotypes you associate with Rust and Rust programmers?
- sidlls 4y ago
  The belief that the problem of memory safety that Rust has some compile-time protections against is the only problem (or so much more important problem that the rest almost don’t matter) of programming, and that therefore Rust is the only sane choice to use for any project. There’s a reason that memes like “Rust Evangelism Strike Force” exist. That’s the biggest one, anyway. I picked up Rust for the first time 8 years ago. I liked it: it felt comfortable in my “worn” C++ hands. But the community outside of a very few core individuals who care deeply about the language’s success can be quite toxic and dismissive of anyone who suggests Rust isn’t basically perfect. And it was a bit of a turn off for me, personally.
  - Klonoar 4y ago
    Uh, what? I’ve found Rust as a project and community to be a very self criticizing group - they know when they’ve got it wrong. They’re simply right about one core thing and they’re loud about it when it comes up. Until something proves them wrong and steals their thunder… I don’t know what to tell you.
    - Jensson 4y ago
      In every C++ thread here on HN I've read the past few years there are always some people saying that C++ is unsafe and everyone should migrate to Rust. They might not represent everyone from Rust but that is the part of the Rust community that the C++ community sees the most. Not sure what to do about that really, but I think it caused many C++ programmers to hate the language before they even tried it.
      - GeekyBear 4y ago
        > In every C++ thread here on HN I've read the past few years there are always some people saying that C++ is unsafe Experience shows that memory safety issues are the most common cause of security issues. Microsoft: >As we’ve seen, roughly 70% of the security issues that the [Microsoft Security Response Center] assigns a CVE to are memory safety issues. This means that if that software had been written in Rust, 70% of these security issues would most likely have been eliminated. https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe... Google: >Roughly 70% of all serious security bugs in the Chrome codebase are memory management and safety bugs, Google engineers said this week. https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
        Jensson 4y ago
        You clipped that quote, the aggravating part is where they say that everyone who writes C++ needs to migrate to Rust. Even if it is/was true that will still anger a lot of people when it get posted in every thread about C++.
        GeekyBear 4y ago
        That doesn't excuse downplaying the security issues so common when using languages that do not offer memory safety. Microsoft: >we’ll peek at why we think that Rust represents the best alternative to C and C++ currently available. First, there are plenty of fantastic memory safe languages already available and widely used inside and outside of Microsoft, including .NET languages like C# or F# and other languages like Swift, Go, and Python. We encourage anyone who is currently using C or C++ to consider whether one of these languages would be appropriate to use instead. We, however, are talking about the need for a safe systems programming language (i.e., a language that can build systems other software runs on, like OS kernels). Such workloads need the speed and predictable performance that C, C++, and Rust provide. When thinking about why Rust is a good alternative, it’s good to think about what we can’t afford to give up by switching from C or C++ — namely performance and control. Rust, just like C and C++ has a minimal and optional “runtime”. Rust’s standard library depends on libc for platforms that support it just like C and C++, but the standard library is also optional so running on platforms without an operating system is also possible. Rust, just like C and C++, also gives the programmer fine-grained control on when and how much memory is allocated allowing the programmer to have a very good idea of exactly how the program will perform every time it is run. What this means for performance in terms of raw speed, control, and predictability, is that Rust, C, and C++ can be thought of in similar terms. https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...
- chomp 4y ago
  From my experience, the stereotype is that they are very positive within their own community, very loud and negative towards anything not in the Church of Rust. Of course, this doesn’t fit most Rust programmers, most I’ve met are great people and developers, it’s just the loud people getting the attention.
- rust_is_dead 4y ago
  I have a word in mind, but before that I would ask: what are some safety-critical systems written in Rust? If there are any, how big a role does Rust play in their safety properties? Is it much different from any other programming language? I can already hear faint exclamations about the language's age, but are Rust programmers justified in putting forward claims about safety? Or do they shift to using the word in the sense of "fewer bugs in this particular class" (and nevermind any other effects the language may have on development). Even if we take such a narrow and distorting view of "safety", we can look at, say, "The Power of Ten" and ask how does Rust use fare with each rule, and is it any more advantageous than other languages in use by safety-critical systems.
  - allisdust 4y ago
    I'm curious what caused you to be so annoyed with the language that you had to create a user name out of it :)
    - rust_is_dead 4y ago
  - greenhearth 4y ago
    I don't think anyone ever said it was completely safe. This is a pre-conception on the part of the critics. Every Rust resource I looked at stated that the toolset exists to support inherent safety, but there is still a contract with the programmer that requires them to know what they are doing.
    - rust_is_dead 4y ago
      Rust is "safe" and other languages are "unsafe". Haskell is "pure" while other language are "impure". Some macro systems are "hygienic" while others are "dirty". It is not an accident that the humpty dumpties (language designers) chose to use these particular terms for their semantic distinctions. It's useful for propaganda. The mind encounters a colloquial term and equivocates. This happens in both the critics and the evangelizers. Inferences drawn are then often unjustified.
- MisterTea 4y ago
  The simple fact that they call themselves rustaceans and evangelize the language. It feels the language spread via a religious uprising rather than merit of making good programs easy to write.
  - gspr 4y ago
    Being put off by the evangelizing I can certainly understand – but surely the name "rustaceans" is just some innocent humor.
    - MisterTea 4y ago
      In order to be one of the cool kids you have to identify as one. From my point of view the self identifying and adopting a title is key to the indoctrination process.
      - mustache_kimono 4y ago
        > In order to be one of the cool kids you have to identify as one. You really don't? Every time I read a comment like this, I think, "Who hurt you?"
  - twic 4y ago
    I like Rust the language, and i have found most people in the community to be smart and reasonable. But i also find "Rustaceans" to be rather cringe. I don't think it's specific to Rust; i think this need to form a visible community identity, a brand really, is very common in Silicon Valley culture. Hence why most startups there have cutesy names for employees, people go round sticking logos of software they use on their laptops, etc. The crab is cool though. As language mascots go, it's a lot more adorable than the Gopher or that LISP alien thing, and almost as adorable as Bjarne Stroustrup.
  - sophacles 4y ago
    Ahh yes. Unlike the pythonistas, the gophers, the ziguanas, the lispers, the perl monks, ...
- gspr 4y ago
  I love Rust, it's the most fun I've had programming since first discovering the concept as a kid, with the possible exception of the time I was enamored with Haskell. But one stereotype that I've faced a lot is in connection with the ecosystem. In particular, if you're not satisfied with "rustup everything, then let cargo pull all your deps from crates.io, it just works" as a way of work, you'll sadly face quite a bit of hostility from parts of the community. Seriously; a programming language or its community shouldn't dictate how I assemble and build code! Luckily there are exceptions, and more importantly, the toolchain and ecosystem seem to be getting better in these regards all the time. Still love the language though, and in general the community is very friendly and welcoming (if not always open to criticism).
- Narann 4y ago
  Rust community is nice until you use unsafe. More seriously, the number of peoples you can have a sane discussion about unsafe use is quiet low because when you need to use unsafe is because of a complicate/hard to explain/understand problem. This combined with the (99% of the time valid) safety dogmas brings some to instantly tell you how to not use unsafe with blatantly bad workaround without considering why you _would_ use unsafe at the first place. This safety/anti-unsafe dogma makes some peoples far too vocal. I consider Rust community to be nicer with time, seriously, but I can't say this "I don't understand your problem, but I saw a unsafe, here is a code that doesn't use unsafe" is not a thing. Of course, it's changing, because Rust is more widely use, and "here is when you need unsafe" patterns are emerging. As a Rust user, I'm happy.
  - mustache_kimono 4y ago
    > the number of peoples you can have a sane discussion about unsafe use is quiet low There will always be outliers, but I actually think the Rust community has done a really great job around discussing unsafe in the years since the actix-web issue. See a really great discussion at: https://www.reddit.com/r/rust/comments/we91es/good_example_of_high_performance_rust_project/ https://www.reddit.com/r/rust/comments/we91es/good_example_o... Just some anec-data, but I had some benchmark code which was unsafe (indexing into an array of bytes, no UTF8 validation), that I wanted to rewrite as safe (by leaning on the std lib, so plenty of unsafe under the hood) just to see how much slower it would be, and the code ended up being ~20-30% faster. Sometimes the unsafe patterns we bring with us just don't match the Rust model.
    - Narann 4y ago
      > the Rust community has done a really great job around discussing unsafe in the years since the actix-web issue. I agree, I started Rust before this drama (I wouldn't call that an _issue_, it was the whole culture that goes wrong here), now peoples try to understand why you need unsafe, but it hasn't been the case and for _years_ it was almost impossible. actix-web is the pivot point but the simple fact you need a sad situation like this show how crazy the safety discussions were before, really. Once again: Things are changing and I'm more than happy to see pragmatism in the Rust community. But you can't behave like all of this didn't happens. > Sometimes the unsafe patterns we bring with us just don't match the Rust model. I agree and noticed this too in some cases (compiler does miracles), that's why discussions have to be serious.
packetlost 4y ago
I was very put off from Rust because of the people acting out those stereotypes that I've encountered whenever the topic comes up. But then I decided to just learn it (partially driven by work requirements), and it's honestly great. I don't think we should be rewriting a ton of software just because there's better compiler-level safeguards, but it does make it much harder to shoot yourself in the foot without realizing it. There's some issues, dynamic linking isn't really supported. I've had good luck with various embedded targets, having trialed STM32F4s, RP2040, ESP32-C3, and am waiting on getting an NRF52840. Surprisingly, the ESP32-C3 is the best out of the box experience I've had, but library support is just not there. IMO Rust is a really good language, and it deserves it's place in the toolbelt of most systems programmers. It's not always the right choice, but it's usually a good choice.
- consp 4y ago
  > But then I decided to just learn it (partially driven by work requirements), and it's honestly great. I did for work as well and in my case I do not want to touch it again for quite a while. Cargo is a terrible system with all kinds of hidden and possible broken dependencies you introduce and everything depends highly on the version of rust you use. It's not even close to mature enough to consider using except for test projects. It doesn't fix programmer errors despite every rust user trying to convince me otherwise that all imported crates are perfect. I like the idea of the language somewhat but the entire ecosystem ruins it for me.
  - packetlost 4y ago
    > I did for work as well and in my case I do not want to touch it again for quite a while. Cargo is a terrible system with all kinds of hidden and possible broken dependencies you introduce and everything depends highly on the version of rust you use I've encountered none of this. Of course Cargo is going to have broken libs, it's just a package repo like npm, pypi (+ pip), etc.. The differences between "editions" is pretty large, but I haven't seen much reason to not use the latest release in most cases. The tooling out there is very good at supporting multiple toolchains simultaneously (though, not in the same project, necessarily). > It doesn't fix programmer errors despite every rust user trying to convince me otherwise No engineer who knows what they're talking about will ever say this. You're either spewing lies or are believing the words of people who have no idea what they're talking about, neither of which are good. Rust helps prevent a specific class of memory errors that are very common in C (and to a lesser extent, C++). It still gives you the `unsafe` escape hatch that lets you do almost anything you can do in C. > It's not even close to mature enough to consider using except for test projects. Our production hard-realtime control system begs to differ.
schuyler2d 4y ago
Rust in the kernel is starting with drivers, so if there's a Rust driver for something, it's presumably for hardware that's on a supported platform. Regardless, if you only want C-written work, you're no worse off. The gccrs and rust_gcc_backend projects both are progressing well and would presumably help enable support for other targets only supported by gcc. As far as its affect on Rust, the last year or two, a significant amount of development and affordance has gone into features for "no-std" and its likely that will only accelerate now that Rust is going to be in Linux (and have an opportunity to prove itself there) along with the number of Rust developers that are interested in kernel development. The performance of the NVMe Rust driver in Linux persuaded some of the skeptical kernel devs. With Rust's greater static analysis (and a lot of work around formal methods), in the long run, there will be optimizations that are at least easier if not impossible in C-based codebases. The main advantage is, as you said, the static analysis that radically reduces pointer-related bugs and security vulnerabilities. Another advantage that I'm personally a little skeptical about, but has been expressed by more than one kernel developer, is attracting new talent to becoming kernel developers as the current group is aging.
- mlindner 4y ago
  > The performance of the NVMe Rust driver in Linux persuaded some of the skeptical kernel devs. With Rust's greater static analysis (and a lot of work around formal methods), in the long run, there will be optimizations that are at least easier if not impossible in C-based codebases. Do you have a link to some of the discussion around this? I'm curious to hear what kernel devs thought of the driver and how it was introduced to them. Is there a talk about it? Or mailing list archives? (Or both?)
  - phaylon 4y ago
    From the Linux Plumbers Conference from a couple days ago: https://www.youtube.com/watch?v=Xw9pKeJ-4Bw&t=8040s https://www.youtube.com/watch?v=Xw9pKeJ-4Bw&t=8040s (Warning: It's a longer stream, but the timestamp should be where the driver is shown. There's a table of contents down in the comments.)
__jem 4y ago
There are two in flight projects to bring GCC to Rust: gccrs and rustc_codegen_gcc. These both seem to be making good progress. Otherwise, right now Rust is only being included for drivers, so doesn't have as many portability concerns.
jbirer 4y ago
- sidlls 4y ago
  - deleted 4y ago
    [deleted]
  - mustache_kimono 4y ago
    I think this is basically nonsense. Some of most toxic comments I have ever encountered on HN are people whining about Rust. I've said it before and I'll say it again -- some Rust users need to be confident enough in Rust to allow others to disagree, but, mios dio, it's not as if their interlocutors have found some sweet spot of high minded debate. Moreover, "toxic", to me, is not well-meaning, generally positive people excited about something legitimately technically interesting and new. "Toxic" is repeated flimsy arguments ("Just write better code..." and "Modern C++ doesn't have these issues..." and "Rust doesn't fix ALL BUGS so why even bother?"), mole hill matters of taste ("Egads! The syntax!"), and drive by hype hate (I'm glad the hype has died down enough for Forth to be usable). I gag on this "toxic" line every time I read it, because it usually also includes a boring, retrogressive, small beer, almost American politics-style argument. The joke that comes to mind is we are about 15 minutes from someone claiming "The coastal elites want to force you to use Rust." Yesterday, I saw two comments, one of which claimed Rust was a conspiracy against C++ programmers, another that admitted anti-Rust fervor was about resentment. The energy is they don't want you to win. They are keeping you down. Just yuck.
    - allisdust 4y ago
      I have a theory that all new rust programmers either become evangelists or haters based on whether they are able to cross the borrow checker barrier or not.
      - 4y ago
FnuGk 4y ago
i might be wrong but currently rustc is based on llvm so any platform llvm cant target, rust can target. For the linux kernel it seems like they want to use a gcc frontend for rust (gccrs) that is currently under development. So with gccrs rust should be able to work on any platform gcc supports thus giving it the same portability of the current c code in the kernel.
roblabla 4y ago
> Has the Rust-portability situation been addressed? The rust portability story is in the process of being addressed, by two different projects: gcc-rs[0] adds a Rust frontend to GCC. rustc-codegen-gcc[1] adds a GCC backend to rustc. Both are progressing pretty well, but it will likely still take a while until they reach maturity. > Or will this change restrict the number of platforms the Linux kernel will be usable on? There won't be any Rust inside the Linux core, only for drivers. So no, the linux kernel will always be usable on all platforms. However, the drivers written in Rust won't be usable on platforms not supported by LLVM until a GCC alternative becomes mature. > what will the advantages be? There are multiple: Safety, improved stability, and developer productivity. Compile time will likely take a hit (Rust is famously slow to compile), but I don't expect a big shift in runtime performance (could be slightly better due to the extra opportunities the compiler has for optimization, but it's not super likely). As for having any effects on Rust: it already has! A lot of unstable features got prioritized due to being necessary for the kernel, such as fallible allocations. [0]: https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs - monthly reports at https://thephilbert.io/category/gccrs-status-updates/ https://thephilbert.io/category/gccrs-status-updates/ [1]: https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc - monthly reports at https://blog.antoyo.xyz/ https://blog.antoyo.xyz/

by daptaq 4y ago

dgs_sgd 4y ago

What are the negative stereotypes you associate with Rust and Rust programmers?

sidlls 4y ago
The belief that the problem of memory safety that Rust has some compile-time protections against is the only problem (or so much more important problem that the rest almost don’t matter) of programming, and that therefore Rust is the only sane choice to use for any project. There’s a reason that memes like “Rust Evangelism Strike Force” exist. That’s the biggest one, anyway. I picked up Rust for the first time 8 years ago. I liked it: it felt comfortable in my “worn” C++ hands. But the community outside of a very few core individuals who care deeply about the language’s success can be quite toxic and dismissive of anyone who suggests Rust isn’t basically perfect. And it was a bit of a turn off for me, personally.
- Klonoar 4y ago
  Uh, what? I’ve found Rust as a project and community to be a very self criticizing group - they know when they’ve got it wrong. They’re simply right about one core thing and they’re loud about it when it comes up. Until something proves them wrong and steals their thunder… I don’t know what to tell you.
  - Jensson 4y ago
    In every C++ thread here on HN I've read the past few years there are always some people saying that C++ is unsafe and everyone should migrate to Rust. They might not represent everyone from Rust but that is the part of the Rust community that the C++ community sees the most. Not sure what to do about that really, but I think it caused many C++ programmers to hate the language before they even tried it.
    - GeekyBear 4y ago
      > In every C++ thread here on HN I've read the past few years there are always some people saying that C++ is unsafe Experience shows that memory safety issues are the most common cause of security issues. Microsoft: >As we’ve seen, roughly 70% of the security issues that the [Microsoft Security Response Center] assigns a CVE to are memory safety issues. This means that if that software had been written in Rust, 70% of these security issues would most likely have been eliminated. https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe... Google: >Roughly 70% of all serious security bugs in the Chrome codebase are memory management and safety bugs, Google engineers said this week. https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
      - Jensson 4y ago
        You clipped that quote, the aggravating part is where they say that everyone who writes C++ needs to migrate to Rust. Even if it is/was true that will still anger a lot of people when it get posted in every thread about C++.
        GeekyBear 4y ago
        That doesn't excuse downplaying the security issues so common when using languages that do not offer memory safety. Microsoft: >we’ll peek at why we think that Rust represents the best alternative to C and C++ currently available. First, there are plenty of fantastic memory safe languages already available and widely used inside and outside of Microsoft, including .NET languages like C# or F# and other languages like Swift, Go, and Python. We encourage anyone who is currently using C or C++ to consider whether one of these languages would be appropriate to use instead. We, however, are talking about the need for a safe systems programming language (i.e., a language that can build systems other software runs on, like OS kernels). Such workloads need the speed and predictable performance that C, C++, and Rust provide. When thinking about why Rust is a good alternative, it’s good to think about what we can’t afford to give up by switching from C or C++ — namely performance and control. Rust, just like C and C++ has a minimal and optional “runtime”. Rust’s standard library depends on libc for platforms that support it just like C and C++, but the standard library is also optional so running on platforms without an operating system is also possible. Rust, just like C and C++, also gives the programmer fine-grained control on when and how much memory is allocated allowing the programmer to have a very good idea of exactly how the program will perform every time it is run. What this means for performance in terms of raw speed, control, and predictability, is that Rust, C, and C++ can be thought of in similar terms. https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...
chomp 4y ago
From my experience, the stereotype is that they are very positive within their own community, very loud and negative towards anything not in the Church of Rust. Of course, this doesn’t fit most Rust programmers, most I’ve met are great people and developers, it’s just the loud people getting the attention.
rust_is_dead 4y ago
I have a word in mind, but before that I would ask: what are some safety-critical systems written in Rust? If there are any, how big a role does Rust play in their safety properties? Is it much different from any other programming language? I can already hear faint exclamations about the language's age, but are Rust programmers justified in putting forward claims about safety? Or do they shift to using the word in the sense of "fewer bugs in this particular class" (and nevermind any other effects the language may have on development). Even if we take such a narrow and distorting view of "safety", we can look at, say, "The Power of Ten" and ask how does Rust use fare with each rule, and is it any more advantageous than other languages in use by safety-critical systems.
- allisdust 4y ago
  I'm curious what caused you to be so annoyed with the language that you had to create a user name out of it :)
  - rust_is_dead 4y ago
- greenhearth 4y ago
  I don't think anyone ever said it was completely safe. This is a pre-conception on the part of the critics. Every Rust resource I looked at stated that the toolset exists to support inherent safety, but there is still a contract with the programmer that requires them to know what they are doing.
  - rust_is_dead 4y ago
    Rust is "safe" and other languages are "unsafe". Haskell is "pure" while other language are "impure". Some macro systems are "hygienic" while others are "dirty". It is not an accident that the humpty dumpties (language designers) chose to use these particular terms for their semantic distinctions. It's useful for propaganda. The mind encounters a colloquial term and equivocates. This happens in both the critics and the evangelizers. Inferences drawn are then often unjustified.
MisterTea 4y ago
The simple fact that they call themselves rustaceans and evangelize the language. It feels the language spread via a religious uprising rather than merit of making good programs easy to write.
- gspr 4y ago
  Being put off by the evangelizing I can certainly understand – but surely the name "rustaceans" is just some innocent humor.
  - MisterTea 4y ago
    In order to be one of the cool kids you have to identify as one. From my point of view the self identifying and adopting a title is key to the indoctrination process.
    - mustache_kimono 4y ago
      > In order to be one of the cool kids you have to identify as one. You really don't? Every time I read a comment like this, I think, "Who hurt you?"
- twic 4y ago
  I like Rust the language, and i have found most people in the community to be smart and reasonable. But i also find "Rustaceans" to be rather cringe. I don't think it's specific to Rust; i think this need to form a visible community identity, a brand really, is very common in Silicon Valley culture. Hence why most startups there have cutesy names for employees, people go round sticking logos of software they use on their laptops, etc. The crab is cool though. As language mascots go, it's a lot more adorable than the Gopher or that LISP alien thing, and almost as adorable as Bjarne Stroustrup.
- sophacles 4y ago
  Ahh yes. Unlike the pythonistas, the gophers, the ziguanas, the lispers, the perl monks, ...
gspr 4y ago
I love Rust, it's the most fun I've had programming since first discovering the concept as a kid, with the possible exception of the time I was enamored with Haskell. But one stereotype that I've faced a lot is in connection with the ecosystem. In particular, if you're not satisfied with "rustup everything, then let cargo pull all your deps from crates.io, it just works" as a way of work, you'll sadly face quite a bit of hostility from parts of the community. Seriously; a programming language or its community shouldn't dictate how I assemble and build code! Luckily there are exceptions, and more importantly, the toolchain and ecosystem seem to be getting better in these regards all the time. Still love the language though, and in general the community is very friendly and welcoming (if not always open to criticism).
Narann 4y ago
Rust community is nice until you use unsafe. More seriously, the number of peoples you can have a sane discussion about unsafe use is quiet low because when you need to use unsafe is because of a complicate/hard to explain/understand problem. This combined with the (99% of the time valid) safety dogmas brings some to instantly tell you how to not use unsafe with blatantly bad workaround without considering why you _would_ use unsafe at the first place. This safety/anti-unsafe dogma makes some peoples far too vocal. I consider Rust community to be nicer with time, seriously, but I can't say this "I don't understand your problem, but I saw a unsafe, here is a code that doesn't use unsafe" is not a thing. Of course, it's changing, because Rust is more widely use, and "here is when you need unsafe" patterns are emerging. As a Rust user, I'm happy.
- mustache_kimono 4y ago
  > the number of peoples you can have a sane discussion about unsafe use is quiet low There will always be outliers, but I actually think the Rust community has done a really great job around discussing unsafe in the years since the actix-web issue. See a really great discussion at: https://www.reddit.com/r/rust/comments/we91es/good_example_of_high_performance_rust_project/ https://www.reddit.com/r/rust/comments/we91es/good_example_o... Just some anec-data, but I had some benchmark code which was unsafe (indexing into an array of bytes, no UTF8 validation), that I wanted to rewrite as safe (by leaning on the std lib, so plenty of unsafe under the hood) just to see how much slower it would be, and the code ended up being ~20-30% faster. Sometimes the unsafe patterns we bring with us just don't match the Rust model.
  - Narann 4y ago
    > the Rust community has done a really great job around discussing unsafe in the years since the actix-web issue. I agree, I started Rust before this drama (I wouldn't call that an _issue_, it was the whole culture that goes wrong here), now peoples try to understand why you need unsafe, but it hasn't been the case and for _years_ it was almost impossible. actix-web is the pivot point but the simple fact you need a sad situation like this show how crazy the safety discussions were before, really. Once again: Things are changing and I'm more than happy to see pragmatism in the Rust community. But you can't behave like all of this didn't happens. > Sometimes the unsafe patterns we bring with us just don't match the Rust model. I agree and noticed this too in some cases (compiler does miracles), that's why discussions have to be serious.

packetlost 4y ago

I was very put off from Rust because of the people acting out those stereotypes that I've encountered whenever the topic comes up. But then I decided to just learn it (partially driven by work requirements), and it's honestly great. I don't think we should be rewriting a ton of software just because there's better compiler-level safeguards, but it does make it much harder to shoot yourself in the foot without realizing it. There's some issues, dynamic linking isn't really supported. I've had good luck with various embedded targets, having trialed STM32F4s, RP2040, ESP32-C3, and am waiting on getting an NRF52840. Surprisingly, the ESP32-C3 is the best out of the box experience I've had, but library support is just not there. IMO Rust is a really good language, and it deserves it's place in the toolbelt of most systems programmers. It's not always the right choice, but it's usually a good choice.

consp 4y ago
> But then I decided to just learn it (partially driven by work requirements), and it's honestly great. I did for work as well and in my case I do not want to touch it again for quite a while. Cargo is a terrible system with all kinds of hidden and possible broken dependencies you introduce and everything depends highly on the version of rust you use. It's not even close to mature enough to consider using except for test projects. It doesn't fix programmer errors despite every rust user trying to convince me otherwise that all imported crates are perfect. I like the idea of the language somewhat but the entire ecosystem ruins it for me.
- packetlost 4y ago
  > I did for work as well and in my case I do not want to touch it again for quite a while. Cargo is a terrible system with all kinds of hidden and possible broken dependencies you introduce and everything depends highly on the version of rust you use I've encountered none of this. Of course Cargo is going to have broken libs, it's just a package repo like npm, pypi (+ pip), etc.. The differences between "editions" is pretty large, but I haven't seen much reason to not use the latest release in most cases. The tooling out there is very good at supporting multiple toolchains simultaneously (though, not in the same project, necessarily). > It doesn't fix programmer errors despite every rust user trying to convince me otherwise No engineer who knows what they're talking about will ever say this. You're either spewing lies or are believing the words of people who have no idea what they're talking about, neither of which are good. Rust helps prevent a specific class of memory errors that are very common in C (and to a lesser extent, C++). It still gives you the `unsafe` escape hatch that lets you do almost anything you can do in C. > It's not even close to mature enough to consider using except for test projects. Our production hard-realtime control system begs to differ.

schuyler2d 4y ago

Rust in the kernel is starting with drivers, so if there's a Rust driver for something, it's presumably for hardware that's on a supported platform. Regardless, if you only want C-written work, you're no worse off. The gccrs and rust_gcc_backend projects both are progressing well and would presumably help enable support for other targets only supported by gcc. As far as its affect on Rust, the last year or two, a significant amount of development and affordance has gone into features for "no-std" and its likely that will only accelerate now that Rust is going to be in Linux (and have an opportunity to prove itself there) along with the number of Rust developers that are interested in kernel development. The performance of the NVMe Rust driver in Linux persuaded some of the skeptical kernel devs. With Rust's greater static analysis (and a lot of work around formal methods), in the long run, there will be optimizations that are at least easier if not impossible in C-based codebases. The main advantage is, as you said, the static analysis that radically reduces pointer-related bugs and security vulnerabilities. Another advantage that I'm personally a little skeptical about, but has been expressed by more than one kernel developer, is attracting new talent to becoming kernel developers as the current group is aging.

mlindner 4y ago
> The performance of the NVMe Rust driver in Linux persuaded some of the skeptical kernel devs. With Rust's greater static analysis (and a lot of work around formal methods), in the long run, there will be optimizations that are at least easier if not impossible in C-based codebases. Do you have a link to some of the discussion around this? I'm curious to hear what kernel devs thought of the driver and how it was introduced to them. Is there a talk about it? Or mailing list archives? (Or both?)
- phaylon 4y ago
  From the Linux Plumbers Conference from a couple days ago: https://www.youtube.com/watch?v=Xw9pKeJ-4Bw&t=8040s https://www.youtube.com/watch?v=Xw9pKeJ-4Bw&t=8040s (Warning: It's a longer stream, but the timestamp should be where the driver is shown. There's a table of contents down in the comments.)

__jem 4y ago

There are two in flight projects to bring GCC to Rust: gccrs and rustc_codegen_gcc. These both seem to be making good progress. Otherwise, right now Rust is only being included for drivers, so doesn't have as many portability concerns.

jbirer 4y ago

sidlls 4y ago
- deleted 4y ago
  [deleted]
- mustache_kimono 4y ago
  I think this is basically nonsense. Some of most toxic comments I have ever encountered on HN are people whining about Rust. I've said it before and I'll say it again -- some Rust users need to be confident enough in Rust to allow others to disagree, but, mios dio, it's not as if their interlocutors have found some sweet spot of high minded debate. Moreover, "toxic", to me, is not well-meaning, generally positive people excited about something legitimately technically interesting and new. "Toxic" is repeated flimsy arguments ("Just write better code..." and "Modern C++ doesn't have these issues..." and "Rust doesn't fix ALL BUGS so why even bother?"), mole hill matters of taste ("Egads! The syntax!"), and drive by hype hate (I'm glad the hype has died down enough for Forth to be usable). I gag on this "toxic" line every time I read it, because it usually also includes a boring, retrogressive, small beer, almost American politics-style argument. The joke that comes to mind is we are about 15 minutes from someone claiming "The coastal elites want to force you to use Rust." Yesterday, I saw two comments, one of which claimed Rust was a conspiracy against C++ programmers, another that admitted anti-Rust fervor was about resentment. The energy is they don't want you to win. They are keeping you down. Just yuck.
  - allisdust 4y ago
    I have a theory that all new rust programmers either become evangelists or haters based on whether they are able to cross the borrow checker barrier or not.
    - 4y ago

FnuGk 4y ago

i might be wrong but currently rustc is based on llvm so any platform llvm cant target, rust can target. For the linux kernel it seems like they want to use a gcc frontend for rust (gccrs) that is currently under development. So with gccrs rust should be able to work on any platform gcc supports thus giving it the same portability of the current c code in the kernel.

roblabla 4y ago

> Has the Rust-portability situation been addressed? The rust portability story is in the process of being addressed, by two different projects: gcc-rs[0] adds a Rust frontend to GCC. rustc-codegen-gcc[1] adds a GCC backend to rustc. Both are progressing pretty well, but it will likely still take a while until they reach maturity. > Or will this change restrict the number of platforms the Linux kernel will be usable on? There won't be any Rust inside the Linux core, only for drivers. So no, the linux kernel will always be usable on all platforms. However, the drivers written in Rust won't be usable on platforms not supported by LLVM until a GCC alternative becomes mature. > what will the advantages be? There are multiple: Safety, improved stability, and developer productivity. Compile time will likely take a hit (Rust is famously slow to compile), but I don't expect a big shift in runtime performance (could be slightly better due to the extra opportunities the compiler has for optimization, but it's not super likely). As for having any effects on Rust: it already has! A lot of unstable features got prioritized due to being necessary for the kernel, such as fallible allocations. [0]: https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs - monthly reports at https://thephilbert.io/category/gccrs-status-updates/ https://thephilbert.io/category/gccrs-status-updates/ [1]: https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc - monthly reports at https://blog.antoyo.xyz/ https://blog.antoyo.xyz/