Hacker News Reader

Safety can include crashing. It's better than returning subtly incorrect results. Yes, there are nil pointers and unnecessary data structures that people keep around, but that's miles ahead of C where an HTTP request and a missing bounds check can inject new code into the application.

If you have a Go program where user input can be executed as code (no cgo, no unsafe), I'd love to see it.

> no cgo

If you're not careful, you will use c code when using os/user and net according to https://www.arp242.net/static-go.html.

This is splitting hairs and arguing semantics. The absolutist statement "Go is memory safe" is simply incorrect.

> The absolutist statement "Go is memory safe" is simply incorrect.

That absolutist statement is also incorrect.

"Go has strong memory safety guarantees" is more accurate. But neither "Go is memory safe" nor "Go is not memory safe" are correct.

Ok, cool. TIL!

Memory safety is a spectrum, and Go is much higher on that spectrum than C/C++.

That's type safety, not memory safety.

... But no, Go isn't memory safe, insofar data races can cause memory corruption.

That is a part of memory safety, not just type safety. Type safety could fix this form of memory issue, yes.