5 ms·

> If you're tired of hearing about memory safety, this article is for you. Tell me more about memory safety, any time; just hold the Rust. Rust skeptics are n

> If you're tired of hearing about memory safety, this article is for you. Tell me more about memory safety, any time; just hold the Rust. Rust skeptics are not memory safety skeptics. Hopefully, there are no memory safety skeptics, other than rhetorical strawmen.

Yoric 1y ago
I've spoken with quite a few C++ developers who swear that they don't need memory safety tooling because they're good enough to achieve it on their own. More than a few also expect that the worst that can happen from breaking memory safety is a SEGFAULT, which also suggests that they don't understand memory safety. So, I'd say that there is still some outreach to do on the topic. On the other hand, you're absolutely right that Rust is only one of the many ways to get there.
- kazinator 1y ago
  OK, so those are skeptics about tooling, not about memory safety per se. And not even about tooling per se, since achieving safety on their own doesn't literally mean on their own; they are relying on tooling. True Scotsman's "on your own" means working in assembly language, in which you have to carefully manage even just calling a function and returning from it: not leaving stray arguments on the stack, saving and restoring all callee-saved register that are used in the function and so on. Someone who thinks that their job is not to have segfaults is pretty green, obviously.
  - yjftsjthsd-h 1y ago
    > True Scotsman's "on your own" means working in assembly language, in which you have to carefully manage even just calling a function and returning from it: not leaving stray arguments on the stack, saving and restoring all callee-saved register that are used in the function and so on. I've actually been trying to figure out if it's practical to write assembly but then use a proof assistant to guarantee that it maintains safety. Weirdly feels easier than C insofar as that you don't have (C's) undefined behavior to contend with. But formal methods are a whole thing and I'm very very new to them so it remains to be seen whether this is actually a good idea, or awful and stupid:) (Edit: ...or merely impractical, for that matter)
    - adrianN 1y ago
      That doesn’t sound so different from using a programming language that guarantees safety. The compiler proves that its translations are safe.
    - mrkeen 1y ago
      It would be impractical. It would be monumental to even specify what 'safe' means in that degree of freedom, let alone allow/reject arbitrary assembly code according to the spec. E.g. Trying to reject string operations which write beyond the trailing \0. At assembly level, \0 is only one of many possible conventions for bounding a string. E.g. maybe free() is allowed to write past 0s. So you'd need to decide whether it's safe depending on context.
      - yjftsjthsd-h 1y ago
        Well yeah, I assumed if I was doing formal verification that that would necessarily involve fully specifying/tracking data sizes, which would mean that all strings would be pascal strings (at least internally; obviously it might be necessary to tack on a \0 for compatibility with external code).
    - AlotOfReading 1y ago
      You could do that and some very expensive aerospace tooling exists in that direction (for verifying compiler outputs), but an easier way is to use sanitizers on a best effort basis. You can either use something like AFL++ with QAsan or use retrowrite to insert whatever you want into the binary as if it was a normal compiled program.
    - Yoric 1y ago
      You should take a look at TAL (the Typed Assembly Language) and DTAL (the Dependently Typed Assembly Language). The latter was designed specifically to support co-writing assembly and formal proofs.
  - Yoric 1y ago
    I'm not entirely certain what you mean. These C++ developers I'm mentioning are all at least senior (some of them staff+), which makes their remarks on segfaults scary, because clearly, they haven't realized that a segfault is the best case scenario, not the worst one. This means that they very much need a refresher course on memory safety and why it matters. The fact that they assume that they're good enough to avoid memory errors without tooling despite the fact that most of these errors are invisible and may remain invisible for years before being discovered is a second red flag, because it strongly suggest that they misunderstand the difficulty. Of course, the conversation between you and I is complicated by the fact that the same words "memory safety" could apply to the programming language/tooling or to the compiled binary.
    - winterlights 1y ago
      The whole discussion sucks, because Rust is not memory safe, and can easily be worse than C and C++ regarding memory safety. Memory unsafety is entirely possible in Rust[0]. [0]: https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-...
      - Yoric 1y ago
        Not sure where that comes from. We're not even discussing Rust in this thread.
      - yencabulator 11mo ago
        Looks like unsafe code doing the actual freeing.. unsafe Rust has never been claimed to be memory safe.
- blub 1y ago
  Sounds like a straw-man. I know developers who are good enough to achieve it on their own, but they use the tooling anyway, because one can’t write perfect code always: feature requests might be coming in too fast, team members have different skill levels, dev turnover happens, etc. Furthermore, memory bugs still can be considered by teams as just another bug, so they might not get prioritised. The only significant difference is that there’s lots of criminal energy targeting them, otherwise nobody would care much.
Ar-Curunir 1y ago
> Hopefully, there are no memory safety skeptics, other than rhetorical strawmen. There are plenty of such skeptics. It's why Google, Microsoft, etc all needed to publish things like "70% of our vulnerabilities are memory-safety linked". Even today, the increasing popularity of Zig indicates that memory-safety is not taken as a baseline.
- MeetingsBrowser 1y ago
  Good point. There are even two posts about Zig on the front page along side this post.
- pjmlp 1y ago
  Indeed Zig would be interesting 30 years ago, when Modula-2 and Object Pascal were all over the place, and writing full games in Assembly was still seen as pretty normal.
AlotOfReading 1y ago
I wish memory safety skepticism was nothing more than a rhetorical strawman. It's not hard to find prominent people who think differently though. Take Herb Sutter for example, who argues that "memory safety" as defined in this article is an extreme goal and we should instead focus on a more achievable 95% safety instead to spend the remaining effort on other types of safety. I can also point to more extreme skeptics like Dan O'dowd, who argue that memory safety is just about getting gud and you don't actually need language affordances. Discussions about this topic would be a lot less heated if everyone was on the same page to start. They're not. It's taken advocates years of effort to get to the point where we can start talking about memory safety without immediate negative reactions and that process is still ongoing.
- bmurphy1976 1y ago
  I prefer to treat testing like insurance. You purchase enough insurance to get the coverage you need, and not a penny more. Anything beyond that could be invested better. Same thing with tests, get the coverage you need to build the confidence in your codebase, but don't tie yourself in knots trying to get that last 10%. It's not worth it. Create some manual and integration tests and move one. I feel like type safety, memory safety, thread safety, etc. are are all similar. Building a physics core to simulate the stability of your nuclear stockpile? The typing should be second to none. Building yet another CSV exporter? Who gives a damn. Context is so damn important.
  - Yoric 1y ago
    > Building yet another CSV exporter? Who gives a damn. The problem with memory unsafe code is that it can have unexpected and unpredictable side-effects. Such as subtly altering the critical data you're exporting, of letting an attacker take control of your CSV exporter. In other words, you need quite a lot of context to figure out that a memory bug in your CSV exporter won't be used for escalation. Figuring out that context, documenting it and making sure that the context never changes for the lifetime of your code? That sounds like a much complex proposition that using memory-safe tools in the first place.
  - AlotOfReading 1y ago
vlovich123 1y ago
I’m curious, what memory safe alternative is there for a C/C++ codebase that doesn’t give up performance? Also for what it’s worth Rust ports tend to perform faster according to Russinovich. Part of that may be second system syndrome although the more likely explanation is that the default std library is just better optimized (eg hash tables in Rust are significantly better than unordered_map)
- bluGill 1y ago
  Ada has been around for years. The approach to memory safety isn't as strong as Rust, but it is a lot strong than C or C++. C++ is also adding a lot of memory safety, it is a lot easier to bypass than it is in Rust (though I've seen Rust code where everything is marked unsafe), but you still get some memory safety if you try. All benchmarks between Ada, C, C++, and Rust (and others) should come down to a wash. A skilled programmer can find a difference but it won't be significant. A skilled C++ programmer wouldn't be using unordered_map so it is unfair to point out you can use something bad.
  - vlovich123 1y ago
    It has but you need spark too to avoid the runtime overhead. And I haven’t seen adoption of Ada in the broader industry so I wouldn’t pick it based on that. I would need to understand why it remains limited to industry’s that mandate government certification. > A skilled C++ programmer wouldn't be using unordered_map so it is unfair to point out you can use something bad. Pretending defaults don’t matter is naive especially in a language that is so hostile to being easy to add 3p dependencies (even without that defaults matter).
    - pjmlp 1y ago
      Rust has plenty of runtime overhead, or do you think Vec is fully static checked? There are other examples for other data structures.
  - BeetleB 1y ago
    > A skilled C++ programmer wouldn't be using unordered_map so it is unfair to point out you can use something bad. C++ isn't my primary language. Pray tell - what's wrong with unordered_map, and what's the alternative?
littlestymaar 1y ago
> Rust skeptics are not memory safety skeptics Definitely not all of them, yes. > Hopefully, there are no memory safety skeptics, other than rhetorical strawmen. You'll find the reality disappointing then…
nightpool 1y ago
There was an article about Zig on the front page just a few hours ago that attracted many "Why do I need memory safety?" comments. The fact that new languages like Zig aren't taking memory safety as a foundational design goal should be evidence enough that many people are still skeptical about its value
- tptacek 1y ago
  Zig's approach to memory safety is an open question. I don't like it (obviously, a very subjective statement), but as more software is written in it, we'll get empirical data about whether Zig's bet pays off. It very well might.
  - nightpool 1y ago
    The post in question had early empirical data comparing bug reports from Node, Bun and Deno. It wasn't the main focus of the article, and I would love to see a deeper dive, but it showed that Bun had almost 8x the amount of "crash" or "segfault" bug reports on Github as Deno, despite having almost the same amount of total issues created. (4% of bug reports for Deno are crashes, 26% of bug reports for Bun are crashes). This matches my experience with the runtimes in question—I tried Bun out for a very small project and ran into 3 distinct crashes, often in very simple parts of the code like command line processing. Obviously not every crash / null-pointer dereference is a memory safety issue, but I think most people would agree that Zig does not seem to make bug-free software easier to write.
    - tptacek 1y ago
      Go programs "segmentation fault" all the time. They're still memory-safe.
      - tcfhgj 1y ago
        I don't think so...
        1y ago
antonvs 1y ago
> Tell me more about memory safety What is it you want to hear about memory safety? If you’re willing to accept the tradeoffs of an automatic garbage collector, memory safety has been a solved problem for decades, and there’s not a whole lot to tell you about it other than learning about widespread, mature technology. But if you have some good reason to avoid that technology, then your options are far more limited, and there are good reasons that Rust dominates that conversation. So the question stands - what is it you want to hear more about?
pjmlp 1y ago
For example, everyone that is already more than happy using any form of automatic resource managed programming language. Many have no use for borrow checker, and there is already enough choice with ML inspired type systems.

Yoric 1y ago

I've spoken with quite a few C++ developers who swear that they don't need memory safety tooling because they're good enough to achieve it on their own. More than a few also expect that the worst that can happen from breaking memory safety is a SEGFAULT, which also suggests that they don't understand memory safety. So, I'd say that there is still some outreach to do on the topic. On the other hand, you're absolutely right that Rust is only one of the many ways to get there.

kazinator 1y ago
OK, so those are skeptics about tooling, not about memory safety per se. And not even about tooling per se, since achieving safety on their own doesn't literally mean on their own; they are relying on tooling. True Scotsman's "on your own" means working in assembly language, in which you have to carefully manage even just calling a function and returning from it: not leaving stray arguments on the stack, saving and restoring all callee-saved register that are used in the function and so on. Someone who thinks that their job is not to have segfaults is pretty green, obviously.
- yjftsjthsd-h 1y ago
  > True Scotsman's "on your own" means working in assembly language, in which you have to carefully manage even just calling a function and returning from it: not leaving stray arguments on the stack, saving and restoring all callee-saved register that are used in the function and so on. I've actually been trying to figure out if it's practical to write assembly but then use a proof assistant to guarantee that it maintains safety. Weirdly feels easier than C insofar as that you don't have (C's) undefined behavior to contend with. But formal methods are a whole thing and I'm very very new to them so it remains to be seen whether this is actually a good idea, or awful and stupid:) (Edit: ...or merely impractical, for that matter)
  - adrianN 1y ago
    That doesn’t sound so different from using a programming language that guarantees safety. The compiler proves that its translations are safe.
  - mrkeen 1y ago
    It would be impractical. It would be monumental to even specify what 'safe' means in that degree of freedom, let alone allow/reject arbitrary assembly code according to the spec. E.g. Trying to reject string operations which write beyond the trailing \0. At assembly level, \0 is only one of many possible conventions for bounding a string. E.g. maybe free() is allowed to write past 0s. So you'd need to decide whether it's safe depending on context.
    - yjftsjthsd-h 1y ago
      Well yeah, I assumed if I was doing formal verification that that would necessarily involve fully specifying/tracking data sizes, which would mean that all strings would be pascal strings (at least internally; obviously it might be necessary to tack on a \0 for compatibility with external code).
  - AlotOfReading 1y ago
    You could do that and some very expensive aerospace tooling exists in that direction (for verifying compiler outputs), but an easier way is to use sanitizers on a best effort basis. You can either use something like AFL++ with QAsan or use retrowrite to insert whatever you want into the binary as if it was a normal compiled program.
  - Yoric 1y ago
    You should take a look at TAL (the Typed Assembly Language) and DTAL (the Dependently Typed Assembly Language). The latter was designed specifically to support co-writing assembly and formal proofs.
- Yoric 1y ago
  I'm not entirely certain what you mean. These C++ developers I'm mentioning are all at least senior (some of them staff+), which makes their remarks on segfaults scary, because clearly, they haven't realized that a segfault is the best case scenario, not the worst one. This means that they very much need a refresher course on memory safety and why it matters. The fact that they assume that they're good enough to avoid memory errors without tooling despite the fact that most of these errors are invisible and may remain invisible for years before being discovered is a second red flag, because it strongly suggest that they misunderstand the difficulty. Of course, the conversation between you and I is complicated by the fact that the same words "memory safety" could apply to the programming language/tooling or to the compiled binary.
  - winterlights 1y ago
    The whole discussion sucks, because Rust is not memory safe, and can easily be worse than C and C++ regarding memory safety. Memory unsafety is entirely possible in Rust[0]. [0]: https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-...
    - Yoric 1y ago
      Not sure where that comes from. We're not even discussing Rust in this thread.
    - yencabulator 11mo ago
      Looks like unsafe code doing the actual freeing.. unsafe Rust has never been claimed to be memory safe.
blub 1y ago
Sounds like a straw-man. I know developers who are good enough to achieve it on their own, but they use the tooling anyway, because one can’t write perfect code always: feature requests might be coming in too fast, team members have different skill levels, dev turnover happens, etc. Furthermore, memory bugs still can be considered by teams as just another bug, so they might not get prioritised. The only significant difference is that there’s lots of criminal energy targeting them, otherwise nobody would care much.

Ar-Curunir 1y ago

> Hopefully, there are no memory safety skeptics, other than rhetorical strawmen. There are plenty of such skeptics. It's why Google, Microsoft, etc all needed to publish things like "70% of our vulnerabilities are memory-safety linked". Even today, the increasing popularity of Zig indicates that memory-safety is not taken as a baseline.

MeetingsBrowser 1y ago
Good point. There are even two posts about Zig on the front page along side this post.
pjmlp 1y ago
Indeed Zig would be interesting 30 years ago, when Modula-2 and Object Pascal were all over the place, and writing full games in Assembly was still seen as pretty normal.

AlotOfReading 1y ago

I wish memory safety skepticism was nothing more than a rhetorical strawman. It's not hard to find prominent people who think differently though. Take Herb Sutter for example, who argues that "memory safety" as defined in this article is an extreme goal and we should instead focus on a more achievable 95% safety instead to spend the remaining effort on other types of safety. I can also point to more extreme skeptics like Dan O'dowd, who argue that memory safety is just about getting gud and you don't actually need language affordances. Discussions about this topic would be a lot less heated if everyone was on the same page to start. They're not. It's taken advocates years of effort to get to the point where we can start talking about memory safety without immediate negative reactions and that process is still ongoing.

bmurphy1976 1y ago
I prefer to treat testing like insurance. You purchase enough insurance to get the coverage you need, and not a penny more. Anything beyond that could be invested better. Same thing with tests, get the coverage you need to build the confidence in your codebase, but don't tie yourself in knots trying to get that last 10%. It's not worth it. Create some manual and integration tests and move one. I feel like type safety, memory safety, thread safety, etc. are are all similar. Building a physics core to simulate the stability of your nuclear stockpile? The typing should be second to none. Building yet another CSV exporter? Who gives a damn. Context is so damn important.
- Yoric 1y ago
  > Building yet another CSV exporter? Who gives a damn. The problem with memory unsafe code is that it can have unexpected and unpredictable side-effects. Such as subtly altering the critical data you're exporting, of letting an attacker take control of your CSV exporter. In other words, you need quite a lot of context to figure out that a memory bug in your CSV exporter won't be used for escalation. Figuring out that context, documenting it and making sure that the context never changes for the lifetime of your code? That sounds like a much complex proposition that using memory-safe tools in the first place.
- AlotOfReading 1y ago

vlovich123 1y ago

I’m curious, what memory safe alternative is there for a C/C++ codebase that doesn’t give up performance? Also for what it’s worth Rust ports tend to perform faster according to Russinovich. Part of that may be second system syndrome although the more likely explanation is that the default std library is just better optimized (eg hash tables in Rust are significantly better than unordered_map)

bluGill 1y ago
Ada has been around for years. The approach to memory safety isn't as strong as Rust, but it is a lot strong than C or C++. C++ is also adding a lot of memory safety, it is a lot easier to bypass than it is in Rust (though I've seen Rust code where everything is marked unsafe), but you still get some memory safety if you try. All benchmarks between Ada, C, C++, and Rust (and others) should come down to a wash. A skilled programmer can find a difference but it won't be significant. A skilled C++ programmer wouldn't be using unordered_map so it is unfair to point out you can use something bad.
- vlovich123 1y ago
  It has but you need spark too to avoid the runtime overhead. And I haven’t seen adoption of Ada in the broader industry so I wouldn’t pick it based on that. I would need to understand why it remains limited to industry’s that mandate government certification. > A skilled C++ programmer wouldn't be using unordered_map so it is unfair to point out you can use something bad. Pretending defaults don’t matter is naive especially in a language that is so hostile to being easy to add 3p dependencies (even without that defaults matter).
  - pjmlp 1y ago
    Rust has plenty of runtime overhead, or do you think Vec is fully static checked? There are other examples for other data structures.
- BeetleB 1y ago
  > A skilled C++ programmer wouldn't be using unordered_map so it is unfair to point out you can use something bad. C++ isn't my primary language. Pray tell - what's wrong with unordered_map, and what's the alternative?

littlestymaar 1y ago

> Rust skeptics are not memory safety skeptics Definitely not all of them, yes. > Hopefully, there are no memory safety skeptics, other than rhetorical strawmen. You'll find the reality disappointing then…

nightpool 1y ago

There was an article about Zig on the front page just a few hours ago that attracted many "Why do I need memory safety?" comments. The fact that new languages like Zig aren't taking memory safety as a foundational design goal should be evidence enough that many people are still skeptical about its value

tptacek 1y ago
Zig's approach to memory safety is an open question. I don't like it (obviously, a very subjective statement), but as more software is written in it, we'll get empirical data about whether Zig's bet pays off. It very well might.
- nightpool 1y ago
  The post in question had early empirical data comparing bug reports from Node, Bun and Deno. It wasn't the main focus of the article, and I would love to see a deeper dive, but it showed that Bun had almost 8x the amount of "crash" or "segfault" bug reports on Github as Deno, despite having almost the same amount of total issues created. (4% of bug reports for Deno are crashes, 26% of bug reports for Bun are crashes). This matches my experience with the runtimes in question—I tried Bun out for a very small project and ran into 3 distinct crashes, often in very simple parts of the code like command line processing. Obviously not every crash / null-pointer dereference is a memory safety issue, but I think most people would agree that Zig does not seem to make bug-free software easier to write.
  - tptacek 1y ago
    Go programs "segmentation fault" all the time. They're still memory-safe.
    - tcfhgj 1y ago
      I don't think so...
      - 1y ago

antonvs 1y ago

> Tell me more about memory safety What is it you want to hear about memory safety? If you’re willing to accept the tradeoffs of an automatic garbage collector, memory safety has been a solved problem for decades, and there’s not a whole lot to tell you about it other than learning about widespread, mature technology. But if you have some good reason to avoid that technology, then your options are far more limited, and there are good reasons that Rust dominates that conversation. So the question stands - what is it you want to hear more about?

pjmlp 1y ago

For example, everyone that is already more than happy using any form of automatic resource managed programming language. Many have no use for borrow checker, and there is already enough choice with ML inspired type systems.