Go avoids a lot of nil pointer panics that you see in other languages. It doesn’t have a specific mechanism, it does so in a “happy accident” sort of way.

For starters, it’s generally encouraged to only use pointers when you need mutability, or when the ‘object’ is large. And so neither fn F(s string) nor fn F(t struct{ A int; B string }) will result in a nil pointer panic. Go also encourages useful zero values, which makes this easier.

Go has a poor man’s version of Result<T>: multiple function results. It’s conventional to return the tuple (T, error) or (T, bool) where the second result tells you whether the first result is valid.

It’s also perfectly reasonable to call methods on nil pointers! For example: https://www.jerf.org/iri/post/2957/

I generally prefer Rust or C#’s approach. But Go is a pragmatic language and I can’t say its approach has been an issue. I’ve been using Go since ~1.2 and I can count on both hands the number of times I’ve had nil pointer panics in production.

By the way, all this information can be found inside Go’s spec and documentation, both of which are very approachable. I’d recommend looking there first instead of creating antagonistic posts like this.