5 ms·

I suspect a lot of the toxic discourse originally comes from folks not understanding each other's use cases and priorities. For some, memory safety is a means

I suspect a lot of the toxic discourse originally comes from folks not understanding each other's use cases and priorities. For some, memory safety is a means to an end: delivering value. In this perspective, one must weigh the benefits of improving memory safety against the complexity costs of proving memory safety. In some situations, the improvement is too small and the added complexity is too much. Some apps and some embedded situations come to mind. Languages like Odin and Zig can be stellar in these situations. For others, memory safety is a responsibility, and upholding it is a basic requirement of modern software no matter what costs we need to pay for it, and if the world would just accept that, then we as a society could move past the days of rampant vulnerabilities and odd memory bugs. Both sides are equally compelling, to me at least. What I hope people can learn is that it really depends on the situation. There is a place and time for both approaches. Once we can accept that, I think the toxicity will dissipate.

staticassertion 4y ago
This is exactly the way I see it. I view the bar for developer responsibility to be much higher than some others do. I suspect it's because I come from the world of information security where we deal very directly with the consequences of not having a higher bar. To me, the idea that a new language would be anything other than entirely memory safe, unless it is very domain specific to areas where that's not important, is just another example of developers lowering the bar. And I'm fine calling that out and being called a zealot or whatever.
- verdagon 4y ago
  You didn't explicitly say this, but for anyone who might misinterpret your comment to imply that any memory-unsafe should be specifically targeted at certain small domains: A vast swath of the programming world doesn't need the level of memory safety that Rust has: apps and webapps are generally sandboxed and only talk to a trusted first-party domain, and games don't need memory safety if they're single player, or even multiplayer co-op against AI. There are a lot of aspects of the industry like this. We do need memory safety in any case that receives untrusted input (for security reasons), cases that handle multiple users' data (for privacy reasons), and safety critical software. There are plenty more cases like these too. Languages like Rust (or even more memory-safe languages) are a stellar choice for this side of the programming world, but not necessarily the other side. Creating simple languages to serve the purposes best served by simple languages is a good thing, and I celebrate and applaud Odin and Zig for that. It's up to the individual developer to make a responsible choice based on their situation, and any developer that uses the wrong language for the wrong situation is indeed guilty of lowering the bar.
  - staticassertion 4y ago
    Yeah, to be clear, some domains are different. Gaming is one example of a domain where "best effort" memory safety is perfectly acceptable. Would I prefer full memory safety? Sure, but we don't see games as an attack vector in the wild very often and there are good reasons for that. If someone wants to build a game in a language that's best-effort memory safety go for it. Similarly, CLI applications are often never called from an untrusted context and often provide semantic power that is equivalent to code execution anyways, so again I'd love to see memory safety, but I'm not going to care that much. But these are exceptions - you'd still want to way whatever you're getting from memory-unsafe-language-X against just using a memory safe language. The default should be memory safety. Given that we have Go, Rust, Java, and more, there are few situations where memory safety isn't an easy option. Not zero, just few.
    - verdagon 4y ago
      I'm not sure I'd characterize Rust as an easy enough option for most people/cases, or that there's just a "few" situations, but apart from that I like your perspective, well said.
    - steveklabnik 4y ago
      Even without it being an attack vector, memory unsafety in games can suck as a user. I play a game that’s high stakes, when you die you lose your gear. I’ve lost two full sets of endgame gear recently because of a crash due to an EXCEPTION_ACESS_VIOLATION. I found it kinda funny in a dark way. Anyway, cheats can also happen due to these sorts of issues. And let’s not even start about anticheat; if Battleye or god forbid Vanguard has a memory unsafety issue that’s exploitable, a lot of people are going to be in a very bad place. Single player games maybe but they can still cause problems the end user sees.
      - staticassertion 4y ago
        Sure, I think all developers, virtually regardless of domain, should strive for higher quality software. The bar is really low. But the fight I choose is memory safety in cases where end user security will be harmed without it - to me, that's such a pathetically low bar already, surely people can't argue against it (they can and they do lol I hate this industry tbh).
- lifthrasiir 4y ago
  I think there is some similarity between information security and Rust community; there had been the elephant in the room, and they were the first to actively acknowledge and get rid of it. Since it was long neglected by others, the elimination of the elephant---vulnerability or memory bugs---can be seen as the utmost goal to some (but not all) of them. Others will complain, but as those others were mostly who neglected the elephant from the beginning, their complaints are mixed, some reasonable, some not. It's clear that this situation is far from being ideal, both for who are aware of the elephant and not, but I'm not sure how to mend this gap in understanding.
ArrayBoundCheck 4y ago

staticassertion 4y ago

This is exactly the way I see it. I view the bar for developer responsibility to be much higher than some others do. I suspect it's because I come from the world of information security where we deal very directly with the consequences of not having a higher bar. To me, the idea that a new language would be anything other than entirely memory safe, unless it is very domain specific to areas where that's not important, is just another example of developers lowering the bar. And I'm fine calling that out and being called a zealot or whatever.

verdagon 4y ago
You didn't explicitly say this, but for anyone who might misinterpret your comment to imply that any memory-unsafe should be specifically targeted at certain small domains: A vast swath of the programming world doesn't need the level of memory safety that Rust has: apps and webapps are generally sandboxed and only talk to a trusted first-party domain, and games don't need memory safety if they're single player, or even multiplayer co-op against AI. There are a lot of aspects of the industry like this. We do need memory safety in any case that receives untrusted input (for security reasons), cases that handle multiple users' data (for privacy reasons), and safety critical software. There are plenty more cases like these too. Languages like Rust (or even more memory-safe languages) are a stellar choice for this side of the programming world, but not necessarily the other side. Creating simple languages to serve the purposes best served by simple languages is a good thing, and I celebrate and applaud Odin and Zig for that. It's up to the individual developer to make a responsible choice based on their situation, and any developer that uses the wrong language for the wrong situation is indeed guilty of lowering the bar.
- staticassertion 4y ago
  Yeah, to be clear, some domains are different. Gaming is one example of a domain where "best effort" memory safety is perfectly acceptable. Would I prefer full memory safety? Sure, but we don't see games as an attack vector in the wild very often and there are good reasons for that. If someone wants to build a game in a language that's best-effort memory safety go for it. Similarly, CLI applications are often never called from an untrusted context and often provide semantic power that is equivalent to code execution anyways, so again I'd love to see memory safety, but I'm not going to care that much. But these are exceptions - you'd still want to way whatever you're getting from memory-unsafe-language-X against just using a memory safe language. The default should be memory safety. Given that we have Go, Rust, Java, and more, there are few situations where memory safety isn't an easy option. Not zero, just few.
  - verdagon 4y ago
    I'm not sure I'd characterize Rust as an easy enough option for most people/cases, or that there's just a "few" situations, but apart from that I like your perspective, well said.
  - steveklabnik 4y ago
    Even without it being an attack vector, memory unsafety in games can suck as a user. I play a game that’s high stakes, when you die you lose your gear. I’ve lost two full sets of endgame gear recently because of a crash due to an EXCEPTION_ACESS_VIOLATION. I found it kinda funny in a dark way. Anyway, cheats can also happen due to these sorts of issues. And let’s not even start about anticheat; if Battleye or god forbid Vanguard has a memory unsafety issue that’s exploitable, a lot of people are going to be in a very bad place. Single player games maybe but they can still cause problems the end user sees.
    - staticassertion 4y ago
      Sure, I think all developers, virtually regardless of domain, should strive for higher quality software. The bar is really low. But the fight I choose is memory safety in cases where end user security will be harmed without it - to me, that's such a pathetically low bar already, surely people can't argue against it (they can and they do lol I hate this industry tbh).
lifthrasiir 4y ago
I think there is some similarity between information security and Rust community; there had been the elephant in the room, and they were the first to actively acknowledge and get rid of it. Since it was long neglected by others, the elimination of the elephant---vulnerability or memory bugs---can be seen as the utmost goal to some (but not all) of them. Others will complain, but as those others were mostly who neglected the elephant from the beginning, their complaints are mixed, some reasonable, some not. It's clear that this situation is far from being ideal, both for who are aware of the elephant and not, but I'm not sure how to mend this gap in understanding.

ArrayBoundCheck 4y ago