> "arbitrary concrete behavior" means that at this point anything can happen on the real machine. This implies that everything before this point has to behave according to the specification. "is impossible" is stronger,…
> They also count data race freedom as part of memory safety, which I think is wrong (and contradicts their inclusion of Java and even Go in the list of memory safe languages). For Java, there's no contradiction if you…
> The C definition is that "undefined behavior" can have arbitrary concrete behavior, not that a compiler can assume it does not happen. What is the difference between those? How does a compiler that assumes UB never…
Thanks! I added a reference to that in the blog post. Interestingly, in 2012 Rob Pike explicitly said that Go is "not purely memory safe" because "sharing is legal": https://go.dev/talks/2012/splash.slide#49. However it…
It's impossible in safe Rust (modulo compiler bugs and things like using a debugger to poke in the program's memory from the outside). That's the key difference. Of course unsafe Rust is not memory safe. That's why it…
> The rest is your bug; the variable values coming out of sync with each other, not maintaining the invariant among their values. If the language and its runtime let me break their invariant, then that's their bug, not…
(EDIT: removed the first part since I realized you were replying to some comment further up, not my example.) > Rust has, unfortunately, changed the narrative so that people now believe memory safety is a property of…
See https://www.youtube.com/watch?v=QrrH2lcl9ew for a a presentation of Google's study, which found no measurable difference in productivity between teams using Rust vs Go.
Fair, I misunderstood then. :)
> The perception created by your article is that people shouldn't use Go because it's not memory-safe. Uh, where exactly am I saying or implying that? I am, in fact, saying that Go is much closer to memory-safe…
> it met one common definition of "memory safety", which was essentially "have a garbage collector" This is the first time I hear that being suggested as ever having been the definition of memory safety. Do you have a…
Yeah, Go is often listed with memory-safe languages, I know that. And yet when people define memory safety, Go usually fails to satisfy that definition. That's why I was asking for a definition of memory safety that…
You keep making arguments by assertion without giving sources, so :shrug: yeah this isn't going to go anywhere. I think we actually agree on all of the factual points here, we just don't agree on how languages should be…
Can you point me to the Go definition of memory safety? I searched all over their website, and couldn't find any. (But also, it'd be kind of silly for every language to make up their own definition of memory safety.…
> There is plenty of undefined behavior that can't lead to violating memory safety. For example, in many languages, argument evaluation order is undefined. If you have some code like: You are mixing up non-determinism…
Java also sometimes uses "memory safe" to refer to programs that don't have null pointer exceptions. So in that sense, Java isn't memory safe by construction either. These terms are used slightly differently by…
> Curiously, Go itself is unclear about its memory safety on go.dev. Yeah... I was actually surprised by that when I did the research for the article. I had to go to Wikipedia to find a reference for "Go is considered…
> Another way to reach the same conclusion is to note that this post's argument proves far too much; by the definition used by this author, most other higher-level languages (the author exempts Java, but really only…
Yeah, I can totally believe that this is not a big issue in practice. But I think terms like "memory safety" should have a reasonably strict meaning, and languages that go the extra mile of actually preventing memory…
Yeah I understand that that's how you like to use the term, you've been very clear about that. What I am curious about is whether that's just you. Because the source you gave last time,…
> While you're wondering why I keep claiming Go is a memory-safe language, you can also go ask the ISRG, which says the same thing I am at And yet Go violates the definition they give -- it doesn't prevent out-of-bounds…
> It reads 42h because that address is hardcoded, It is trivial to change this example into an arbitrary int2ptr cast. > Go (or Python, or any of the other mainstream languages that do shared-memory concurrency and…
PLT has used the term "type safety" for a very long time -- so "safety" does not imply a security perspective. And yes it is indeed very different from correctness. But the article doesn't claim that memory safety…
> So, while I can imagine that Miri could be best in class, that class itself has significant limitations. Sure -- but it's still better than writing similar code in C/C++/Zig where no comparable tool exists. (Well, for…
> This is different from no aliasing of Rust, where mutable references of even the same type may not alias. It is different, yes. I never said it was the same. Your claim was that the Rust model is more difficult, that…
> "arbitrary concrete behavior" means that at this point anything can happen on the real machine. This implies that everything before this point has to behave according to the specification. "is impossible" is stronger,…
> They also count data race freedom as part of memory safety, which I think is wrong (and contradicts their inclusion of Java and even Go in the list of memory safe languages). For Java, there's no contradiction if you…
> The C definition is that "undefined behavior" can have arbitrary concrete behavior, not that a compiler can assume it does not happen. What is the difference between those? How does a compiler that assumes UB never…
Thanks! I added a reference to that in the blog post. Interestingly, in 2012 Rob Pike explicitly said that Go is "not purely memory safe" because "sharing is legal": https://go.dev/talks/2012/splash.slide#49. However it…
It's impossible in safe Rust (modulo compiler bugs and things like using a debugger to poke in the program's memory from the outside). That's the key difference. Of course unsafe Rust is not memory safe. That's why it…
> The rest is your bug; the variable values coming out of sync with each other, not maintaining the invariant among their values. If the language and its runtime let me break their invariant, then that's their bug, not…
(EDIT: removed the first part since I realized you were replying to some comment further up, not my example.) > Rust has, unfortunately, changed the narrative so that people now believe memory safety is a property of…
See https://www.youtube.com/watch?v=QrrH2lcl9ew for a a presentation of Google's study, which found no measurable difference in productivity between teams using Rust vs Go.
Fair, I misunderstood then. :)
> The perception created by your article is that people shouldn't use Go because it's not memory-safe. Uh, where exactly am I saying or implying that? I am, in fact, saying that Go is much closer to memory-safe…
> it met one common definition of "memory safety", which was essentially "have a garbage collector" This is the first time I hear that being suggested as ever having been the definition of memory safety. Do you have a…
Yeah, Go is often listed with memory-safe languages, I know that. And yet when people define memory safety, Go usually fails to satisfy that definition. That's why I was asking for a definition of memory safety that…
You keep making arguments by assertion without giving sources, so :shrug: yeah this isn't going to go anywhere. I think we actually agree on all of the factual points here, we just don't agree on how languages should be…
Can you point me to the Go definition of memory safety? I searched all over their website, and couldn't find any. (But also, it'd be kind of silly for every language to make up their own definition of memory safety.…
> There is plenty of undefined behavior that can't lead to violating memory safety. For example, in many languages, argument evaluation order is undefined. If you have some code like: You are mixing up non-determinism…
Java also sometimes uses "memory safe" to refer to programs that don't have null pointer exceptions. So in that sense, Java isn't memory safe by construction either. These terms are used slightly differently by…
> Curiously, Go itself is unclear about its memory safety on go.dev. Yeah... I was actually surprised by that when I did the research for the article. I had to go to Wikipedia to find a reference for "Go is considered…
> Another way to reach the same conclusion is to note that this post's argument proves far too much; by the definition used by this author, most other higher-level languages (the author exempts Java, but really only…
Yeah, I can totally believe that this is not a big issue in practice. But I think terms like "memory safety" should have a reasonably strict meaning, and languages that go the extra mile of actually preventing memory…
Yeah I understand that that's how you like to use the term, you've been very clear about that. What I am curious about is whether that's just you. Because the source you gave last time,…
> While you're wondering why I keep claiming Go is a memory-safe language, you can also go ask the ISRG, which says the same thing I am at And yet Go violates the definition they give -- it doesn't prevent out-of-bounds…
> It reads 42h because that address is hardcoded, It is trivial to change this example into an arbitrary int2ptr cast. > Go (or Python, or any of the other mainstream languages that do shared-memory concurrency and…
PLT has used the term "type safety" for a very long time -- so "safety" does not imply a security perspective. And yes it is indeed very different from correctness. But the article doesn't claim that memory safety…
> So, while I can imagine that Miri could be best in class, that class itself has significant limitations. Sure -- but it's still better than writing similar code in C/C++/Zig where no comparable tool exists. (Well, for…
> This is different from no aliasing of Rust, where mutable references of even the same type may not alias. It is different, yes. I never said it was the same. Your claim was that the Rust model is more difficult, that…