Comment by throwaway894345
Comment by throwaway894345 9 days ago
> Memory safety as long as you don't violate certain rules is what C and C++ also have
There are numbers between 0% and 100%, thus it's possible that Go can be less than 100% memory safe and still far safer than C or C++.
"100% memory safe" is mostly not a thing; it's not a concept that gets quantified this way. The closest thing I think you get to a compromised notion of safety that's actually noteworthy is Zig's allocator behavior (which can in ordinary code theoretically still produce UAF bugs, and UAF bugs --- lifecycle bugs more generally --- are the most pernicious kind of memory safety vulnerability). Most practitioners would still call Zig "memory safe". You can see how much bigger a deal that behavior is than the one we're talking about.
I think the basic takeaway here is not to tie yourself up in nots trying to quantify memory safety. There's a reason Prossimo calls Go memory safe (not "mostly memory safe"), along with Rust, C#, Java, Swift, Python, and JavaScript. Ordinary code written in any of these languages is just not going to have exploitable memory corruption vulnerabilities. Other vulnerabilities, yes!