This is why I love Go. Nobody was asking for this, but they took the time to do it right and continue to Push go as a memory safe, high-level systems language.
That's not what "memory safe" means. "Memory safe" is a term of art meaning "not susceptible to memory corruption exploits", like stack and heap overflows, UAFs, and type confusion. Last I checked, there are essentially no non-contrived memory corruption exploits for Go programs; the best you get are people demonstrating register control on contrived programs.
The definition I'm giving is the same as the ISRG's definition at MemorySafety.org. It's the thing everybody is talking about when they talk about memory safety.
The claim being made here is "big if true", because it would imply a lot more languages than Go "aren't memory safe", despite decades without memory corruption exploits.
The exploits aren't the only issue; they just get a lot of air time.
It's remarkably easy to segfault Go applications with data races. Any object with multiple words (so a slice that's an array pointer, a size, and a capacity. Or a fat pointer with the object pointer and the vtable pointer), can be read in an inconsistent state from two threads which can cause out of bounds reads and writes. And this comes up all the time with how heavily the language encourages concurrency.
It's just difficult to actually exploit because of other considerations that practically add a lot of runtime entropy.
They aren't the only issue in programming language theory, but they are the only issue in the ordinary context in which we discuss "memory safety", such that if someone not in a PLT forum says "is Go memory-safe" and you say "no" you will look a little batty.
The was for a time a vogue for "zero trust networking" and I'm fond of pointing out that the same thing happened there: people would come up with their own axiomatic derivation of what "zero trust" meant, but in reality it was a term of art meaning "non-Google implementations of BeyondCorp".
Terms of art are kryptonite for message board nerds.
You comment on this subject regularly in this way, but opinions do vary. Rob Pike says Go is not purely memory safe under concurrency. I as someone who has written multiple languages would describe it as "memory safe except for a pointer-skew hole undermining concurrency" or maybe say "race-free Go is memory-safe".
Seeing a correctness issue that makes Go not memory safe in some circumstances warrants questioning whether it is memory safe. On balance, you might say it is, but to constantly tell people they are wrong for saying otherwise is policing a shared term.
u8 · · focus · HN ↗
__s · · focus · HN ↗
tptacek · · focus · HN ↗
The definition I'm giving is the same as the ISRG's definition at MemorySafety.org. It's the thing everybody is talking about when they talk about memory safety.
The claim being made here is "big if true", because it would imply a lot more languages than Go "aren't memory safe", despite decades without memory corruption exploits.
monocasa · · focus · HN ↗
It's remarkably easy to segfault Go applications with data races. Any object with multiple words (so a slice that's an array pointer, a size, and a capacity. Or a fat pointer with the object pointer and the vtable pointer), can be read in an inconsistent state from two threads which can cause out of bounds reads and writes. And this comes up all the time with how heavily the language encourages concurrency.
It's just difficult to actually exploit because of other considerations that practically add a lot of runtime entropy.
tptacek · · focus · HN ↗
The was for a time a vogue for "zero trust networking" and I'm fond of pointing out that the same thing happened there: people would come up with their own axiomatic derivation of what "zero trust" meant, but in reality it was a term of art meaning "non-Google implementations of BeyondCorp".
Terms of art are kryptonite for message board nerds.
ghusbands · · focus · HN ↗
Seeing a correctness issue that makes Go not memory safe in some circumstances warrants questioning whether it is memory safe. On balance, you might say it is, but to constantly tell people they are wrong for saying otherwise is policing a shared term.