6 ms·

These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++

These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++. Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though: Rust has an education problem. People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation. I've found very few projects where a bit of poking can't turn up memory safety issues. Even people who are far more skilled programmers than I am routinely write silly mistakes. Unfortunately the response I often hear to bringing these issues up after the code exists is "it's working code, why should I care about these theoretical issues?"

adameasterling 3y ago
> I've found very few projects where a bit of poking can't turn up memory safety issues. I'm working on a Rust project right now, and I'm probably one of those people who are overestimating the correctness of my code! I would love to know about what sorts of memory safety issues you often uncover.
- AlotOfReading 3y ago
  Made it more clear in the original post that I was talking about the correctness of C and C++ code. I haven't observed any notable issues with this in Rust compared to similar languages, but I also don't have the same depth of experience building large systems in it to show me the error of my ways yet.
dboreham 3y ago
I had to read this a couple of times, but I suspect this is about non-rust code, when you cite correctness of code, yes? People don't want to use rust because they think their janky C/C++ is just fine.
jcelerier 3y ago
> People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation Really depends on the field. I heard more than once in my life now that it's better to reboot every night than spend even an afternoon of engineering trying to fix memory leaks.
- outworlder 3y ago
  That's good when it's just about memory leaks. Your missile guidance code can have leaks as long as the missile completes the mission, since it will all be... "garbage collected" anyway. It's not great when you have problems like use after free and pointers going to where they don't belong. Those can cause security vulnerabilities that rebooting won't fix.
  - hajile 3y ago
    Then they make a version that flies farther and it sometimes randomly fails to detonate.
    - toast0 3y ago
      So you write a note mentioning there's a leak, and debug it if there's a need for it. Finding a bug doesn't mean you need to fix it, or fix it right away. Using Rust doesn't preclude resource leaks. I'm pretty sure I've managed to run into resource leaks in all of the languages I've used in production, doesn't matter if they were managed or not. Sometimes limiting the lifetime of the thing that holds resources, and let process (or system) death clean it up works great; sometimes that's terrible, depends on the cost of death/restart, the lifetime between deaths, human intervention required, accuracy of lifetime estimation method, probably some other things. I don't worry too much about leaks that require a restart every year or so; nor would I worry about a leak in a missile that will cause issues beyond the achievable maximum flight time.
- kevin_thibedeau 3y ago
  MongoDB's BSON library calls abort() on malloc failure because they can't be bothered to handle OOM gracefully.
  - tialaramex 3y ago
    That seems completely reasonable. The only interesting case is "There was far too little storage, so we gave up early" e.g. you need 14GB, there is 186MB available, give up. I probably don't want my photo viewer to crash because I tried to open a JPEG that wouldn't fit in RAM, better it just says that's too big and I can pick a different file. Whenever people are imagining they're going to recover despite OOM in low level components they are tripping. Their recovery strategy is going to blow up too, and then they're going to be in a huge mess - just abort when this happens.
marcosdumay 3y ago
The C and C++ ecosystems are suffering from a selection effect, in that the people that have any concern about their code being correct are trying to drop them, while the people comfortable with the language are all the ones that don't know about the problems. I expect the careless unaware culture to get worse with time as more and more aware people manage to leave it.
- logicchains 3y ago
  >the people comfortable with the language are all the ones that don't know about the problems. Or the ones writing code where security doesn't matter, like HFT and video games (the former have no users, and the latter are basically impossible to make crack-resistant even if they're written entirely in Rust).
  - marcosdumay 3y ago
    It's not only security, it's correctness. It's about your software staying running and doing the right thing. I can believe HFT developers think they don't need it.
    - infamouscow 3y ago
      First, 100% of HFT are businesses trying to make money above all else. Security and correctness are secondary to the business requirement of making money, especially when you are uniquely situated to have financially quantified their risk when things go wrong to remain within controlled error bands. Second, HFT developers are using very expensive FGPAs to do trading with network packets. People are quick to reach to some example where their favorite toy is used at some organization, but that's besides the point. The tools for getting code on those FPGAs is horrible and unless Xilinx adopts Rust internally I doubt much will change. Rust can be adopted elsewhere, but that's not what's making the organization money. HFT folks are not persuaded even slightly by these arguments about security and correctness. Jane Street is not a HFT firm and they will gladly tell you that. It helps immensely to understand ones concerns, constraints, and values before assuming they're identical and them swiftly demonizing anyone that dissents. The Rust community really has done itself a massive disservice in alienating everyone that doesn't conform to its monoculture composed mostly of amateurs and unemployable extremists. Of course, this will simply be downvoted by the pathetic and unimpressive. Nobody views this as an opportunity to even try disputing the argument or use it as a legitimate data point that Rust should strive for. They simply want obedience and mindlessness in the monoculture because they lack the tools needed to handle conflict of any kind. It's also why so many features are perpetually stuck as nightly rather than stable. The project does nothing but stultify talent into leaving for genuine innovation.
palata 3y ago
> People dramatically overestimate the correctness of their [C/C++] code Genuinely interested: what do people think of their tons of third-party dependencies in Rust? My experience building Rust projects is that there are orders of magnitudes more dependencies than what would make me comfortable. At least in C/C++ it's much harder to get there.
- kibwen 3y ago
  I use embedded Rust for my day job. We keep our third-party dependencies purposefully minimal, but I adore that they're there when I need to reach for them. Like, we just needed a basic TCP stack to get our PoC up and running, so I can just grab smoltcp and be off to the races. Being written in C or C++ wouldn't obviate our need for a TCP stack, I'd still either need to get it from somewhere else or write it myself. And even if I can't use a third-party dependency for whatever reason (e.g. if it doesn't support no_std mode), I can still usually repurpose their existing test suite to give me confidence in my port or reimplementation.
- deleted 3y ago
  [deleted]
- iknowstuff 3y ago
  Long story short is that I trust their quality. The community is great about vetting unnecessary uses of unsafe code. That’s more than can be said about hand rolled equivalents in C/C++.
  - palata 3y ago
    So if you have 200 dependencies, you trust them just because they don't run what Rust calls "unsafe" code? What about safe code that could be malware?
    - rockdoe 3y ago
      FYI Google and Mozilla audit all their dependencies and share them: * https://chromium.googlesource.com/chromiumos/third_party/rust_crates/+/refs/heads/main/cargo-vet/audits.toml https://chromium.googlesource.com/chromiumos/third_party/rus... * https://searchfox.org/mozilla-central/source/supply-chain/audits.toml https://searchfox.org/mozilla-central/source/supply-chain/au... It's quite likely that most of your dependencies were already audited.
otabdeveloper4 3y ago
Memory safety issues don't matter. There are five orders of magnitude more pwned boxes due to misquoted strings then there are due to memory safety issues. You are searching for a problem that could potentially make Rust useful instead of solving a real existing problem that people actually have.
- DannyBee 3y ago
  So I think rust is maybe not the right hammer, but the first part is definitely wrong. I'm not sure where your data comes from, but memory safety issues are roughly 50% of all exploitable security vulnerabilities. They were also about 50% of all crashes of android apps (null pointer exceptions)
  - otabdeveloper4 3y ago
    Android apps are written in Java and Java is a memory safe language like Rust. (Null pointer exceptions are a logic error, not a memory error.)
azubinski 3y ago
Rust has a single real big problem - Rust adepts still believe in the silver bullet. For professional embedded programmers, faith in silver bullets disappears with the growth of professionalism.

adameasterling 3y ago

> I've found very few projects where a bit of poking can't turn up memory safety issues. I'm working on a Rust project right now, and I'm probably one of those people who are overestimating the correctness of my code! I would love to know about what sorts of memory safety issues you often uncover.

AlotOfReading 3y ago
Made it more clear in the original post that I was talking about the correctness of C and C++ code. I haven't observed any notable issues with this in Rust compared to similar languages, but I also don't have the same depth of experience building large systems in it to show me the error of my ways yet.

dboreham 3y ago

I had to read this a couple of times, but I suspect this is about non-rust code, when you cite correctness of code, yes? People don't want to use rust because they think their janky C/C++ is just fine.

jcelerier 3y ago

> People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation Really depends on the field. I heard more than once in my life now that it's better to reboot every night than spend even an afternoon of engineering trying to fix memory leaks.

outworlder 3y ago
That's good when it's just about memory leaks. Your missile guidance code can have leaks as long as the missile completes the mission, since it will all be... "garbage collected" anyway. It's not great when you have problems like use after free and pointers going to where they don't belong. Those can cause security vulnerabilities that rebooting won't fix.
- hajile 3y ago
  Then they make a version that flies farther and it sometimes randomly fails to detonate.
  - toast0 3y ago
    So you write a note mentioning there's a leak, and debug it if there's a need for it. Finding a bug doesn't mean you need to fix it, or fix it right away. Using Rust doesn't preclude resource leaks. I'm pretty sure I've managed to run into resource leaks in all of the languages I've used in production, doesn't matter if they were managed or not. Sometimes limiting the lifetime of the thing that holds resources, and let process (or system) death clean it up works great; sometimes that's terrible, depends on the cost of death/restart, the lifetime between deaths, human intervention required, accuracy of lifetime estimation method, probably some other things. I don't worry too much about leaks that require a restart every year or so; nor would I worry about a leak in a missile that will cause issues beyond the achievable maximum flight time.
kevin_thibedeau 3y ago
MongoDB's BSON library calls abort() on malloc failure because they can't be bothered to handle OOM gracefully.
- tialaramex 3y ago
  That seems completely reasonable. The only interesting case is "There was far too little storage, so we gave up early" e.g. you need 14GB, there is 186MB available, give up. I probably don't want my photo viewer to crash because I tried to open a JPEG that wouldn't fit in RAM, better it just says that's too big and I can pick a different file. Whenever people are imagining they're going to recover despite OOM in low level components they are tripping. Their recovery strategy is going to blow up too, and then they're going to be in a huge mess - just abort when this happens.

marcosdumay 3y ago

The C and C++ ecosystems are suffering from a selection effect, in that the people that have any concern about their code being correct are trying to drop them, while the people comfortable with the language are all the ones that don't know about the problems. I expect the careless unaware culture to get worse with time as more and more aware people manage to leave it.

logicchains 3y ago
>the people comfortable with the language are all the ones that don't know about the problems. Or the ones writing code where security doesn't matter, like HFT and video games (the former have no users, and the latter are basically impossible to make crack-resistant even if they're written entirely in Rust).
- marcosdumay 3y ago
  It's not only security, it's correctness. It's about your software staying running and doing the right thing. I can believe HFT developers think they don't need it.
  - infamouscow 3y ago
    First, 100% of HFT are businesses trying to make money above all else. Security and correctness are secondary to the business requirement of making money, especially when you are uniquely situated to have financially quantified their risk when things go wrong to remain within controlled error bands. Second, HFT developers are using very expensive FGPAs to do trading with network packets. People are quick to reach to some example where their favorite toy is used at some organization, but that's besides the point. The tools for getting code on those FPGAs is horrible and unless Xilinx adopts Rust internally I doubt much will change. Rust can be adopted elsewhere, but that's not what's making the organization money. HFT folks are not persuaded even slightly by these arguments about security and correctness. Jane Street is not a HFT firm and they will gladly tell you that. It helps immensely to understand ones concerns, constraints, and values before assuming they're identical and them swiftly demonizing anyone that dissents. The Rust community really has done itself a massive disservice in alienating everyone that doesn't conform to its monoculture composed mostly of amateurs and unemployable extremists. Of course, this will simply be downvoted by the pathetic and unimpressive. Nobody views this as an opportunity to even try disputing the argument or use it as a legitimate data point that Rust should strive for. They simply want obedience and mindlessness in the monoculture because they lack the tools needed to handle conflict of any kind. It's also why so many features are perpetually stuck as nightly rather than stable. The project does nothing but stultify talent into leaving for genuine innovation.

palata 3y ago

> People dramatically overestimate the correctness of their [C/C++] code Genuinely interested: what do people think of their tons of third-party dependencies in Rust? My experience building Rust projects is that there are orders of magnitudes more dependencies than what would make me comfortable. At least in C/C++ it's much harder to get there.

kibwen 3y ago
I use embedded Rust for my day job. We keep our third-party dependencies purposefully minimal, but I adore that they're there when I need to reach for them. Like, we just needed a basic TCP stack to get our PoC up and running, so I can just grab smoltcp and be off to the races. Being written in C or C++ wouldn't obviate our need for a TCP stack, I'd still either need to get it from somewhere else or write it myself. And even if I can't use a third-party dependency for whatever reason (e.g. if it doesn't support no_std mode), I can still usually repurpose their existing test suite to give me confidence in my port or reimplementation.
deleted 3y ago
[deleted]
iknowstuff 3y ago
Long story short is that I trust their quality. The community is great about vetting unnecessary uses of unsafe code. That’s more than can be said about hand rolled equivalents in C/C++.
- palata 3y ago
  So if you have 200 dependencies, you trust them just because they don't run what Rust calls "unsafe" code? What about safe code that could be malware?
  - rockdoe 3y ago
    FYI Google and Mozilla audit all their dependencies and share them: * https://chromium.googlesource.com/chromiumos/third_party/rust_crates/+/refs/heads/main/cargo-vet/audits.toml https://chromium.googlesource.com/chromiumos/third_party/rus... * https://searchfox.org/mozilla-central/source/supply-chain/audits.toml https://searchfox.org/mozilla-central/source/supply-chain/au... It's quite likely that most of your dependencies were already audited.

otabdeveloper4 3y ago

Memory safety issues don't matter. There are five orders of magnitude more pwned boxes due to misquoted strings then there are due to memory safety issues. You are searching for a problem that could potentially make Rust useful instead of solving a real existing problem that people actually have.

DannyBee 3y ago
So I think rust is maybe not the right hammer, but the first part is definitely wrong. I'm not sure where your data comes from, but memory safety issues are roughly 50% of all exploitable security vulnerabilities. They were also about 50% of all crashes of android apps (null pointer exceptions)
- otabdeveloper4 3y ago
  Android apps are written in Java and Java is a memory safe language like Rust. (Null pointer exceptions are a logic error, not a memory error.)

azubinski 3y ago

Rust has a single real big problem - Rust adepts still believe in the silver bullet. For professional embedded programmers, faith in silver bullets disappears with the growth of professionalism.