Viewing profile — ralfj

> "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 spec…

> 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…

> 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 d…

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…

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 R…

> 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…

(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 be…

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…

> 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 defin…

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…

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…

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 the…

> 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 li…

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 ar…

> 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 f…

> 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 a…

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 extr…

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 …

> 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 g…

> 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 tha…

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…

> 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 wher…

> 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 …