> An example of extraordinary code would be code that interfaces with and/or pulls in non-memory-safe legacy C code.
That's my point though. Of course calling non-memory safe native code over FFI can lead to memory-safety problems in any language. Likewise using the "unsafe" subset that basically every language has. But none of that is required in Go. It is only required that you mutate shared state from different threads, which is something that I would imagine happens in a lot of Go code codebases since it is an extremely easy mistake to make.
To be clear I think:
1. Go is mostly a memory safe language because it does in fact prevent the most common memory safety issues in C/C++ (UAF, buffer overflows, etc)
2. It is LESS memory safe than other modern memory-sage languages (Rust, Java, C#, Python, etc....)
3. The memory safety issues in Go are very difficult to exploit in code that is not specifically crafted to surface them
That's my point though. Of course calling non-memory safe native code over FFI can lead to memory-safety problems in any language. Likewise using the "unsafe" subset that basically every language has. But none of that is required in Go. It is only required that you mutate shared state from different threads, which is something that I would imagine happens in a lot of Go code codebases since it is an extremely easy mistake to make.
To be clear I think:
1. Go is mostly a memory safe language because it does in fact prevent the most common memory safety issues in C/C++ (UAF, buffer overflows, etc)
2. It is LESS memory safe than other modern memory-sage languages (Rust, Java, C#, Python, etc....)
3. The memory safety issues in Go are very difficult to exploit in code that is not specifically crafted to surface them