I could have forgiven nil checks, but nil checks on interfaces elevated nils to a whole new level, which is annoying, but I do get where they were going with this: you should never nil check an interface. After all,an interface could be valid for a nil value.

There are ways to decently write go and not deal with nil, but as usual, linters defaults makes it impossible and you have to fight with your team before they will understand (we did this at some point and it was a huge improvement).

Don't use pointers at all, always allocate structs on the stack, pass them by value.

You pay the copy price, even with large structs, and that's fine. When there are exceptions, be very explicit about the reason: performance must be critical,not just an optimization.

Don't ever check interfaces for nil, if you need some sort of optional parameter, make a separate function and make it pass an valid object for that interface that's a null object.

These two did improve things substantially

This suggestion fails for values that can be null, need to be mutable or need references from multiple places etc – it's not "just performance penalty".

Go has a problem, "just remember to always do X, never Y" patterns can't be guaranteed across all libraries you use, can't be enforced, can be violated for good reasons, other patterns and as a mistake etc etc.

Shame because otherwise it's a great language, but some mistakes are just no-go.

So close indeed.

They need Go 2 with *T and ?*T - that would be nice language to use.