But I know you'll say that 'import "C"' or 'import "unsafe"' is the same thing as using an unsafe block in rust or such, and really shouldn't count against go.
Which is fair and true, but you're chasing down a pointless detail. The point isn't that go is memory unsafe. It's not. The point is that Go's type-system is not powerful enough to express various types of type-safety, and as such it's an error-prone language where you can expect null pointer exceptions frequently.
You can't. But a runtime panic also very easily causes an outage. At least it's not as subtle.
Still. Rust is infinitely better in this regard. Go feels like a crude hammer, especially regarding the default interaction between deserialization and missing struct members.
You can't. But you can absolutely have a `nil` that will unavoiad runtime panics if you don't check it. And further, you only can't do this because go defines by fiat that the zero-value of a type must be legal. Of course, this is wildly inconvenient and annoying for many types, including those that come bundled in the standard library.
There are other, very convincingly better options to this that many in this thread have been trying to teach you about in the expectation that your responses have been in good faith.
Which is fair and true, but you're chasing down a pointless detail. The point isn't that go is memory unsafe. It's not. The point is that Go's type-system is not powerful enough to express various types of type-safety, and as such it's an error-prone language where you can expect null pointer exceptions frequently.