alt Hacker NewsI’m not aware of any definition of memory safety that allows for segfaults- by definition those are an indication of not being memory safe.
It is true that go is only memory unsafe in a specific scenario, but such things aren’t possible in true memory safe languages like c# or Java. That it only occurs in multithreaded scenarios matters little especially since concurrency is a huge selling point of the language and baked in.
Java can have data races, but those data races cannot be directly exploited into memory safety issues like you can with Go. I’m tired of Go fans treating memory safety as some continuum just because there are many specific classes of how memory safety can be violated and Go protecting against most is somehow the same as protecting against all (which is what being a memory safe language means whether you like it or not).
I’m not aware of any other major language claiming memory safety that is susceptible to segfaults.
Replies
Another canard, unfortunately. "Segfault" is simply Go's reporting convention for things like nil pointer hits. "Segfaults" are not, in fact, part of the definition for memory safety or a threshold condition for it. All due respect to Ralf's Ramblings, but I'm going to rest my case with the Prossimo page on memorysafety.org that I just posted. This isn't a real debate.
Rust is susceptible to segfaults when overflowing the stack. Is Rust not memory safe then?
Of course, Go allows more than that, with data races it's possible to reach use after free or other kinds of memory unsafety, but just segfaults don't mark a language memory unsafe.
Safety is a continuum. It's a simple fact. Feel free to use a term other than memory safety to describe what you're talking about, but so long as you use safety, there's going to be a continuum.
Also, by your definition, e.g. Rust is not memory safe. And "It is true that Rust is only memory unsafe in a specific scenario, but [...]". I hope you agree.