Excessive nil pointer checks in Go
konradreiche.com
Excessive nil pointer checks in Go
1–10 of 116 posts
Re: Excessive nil pointer checks in Go
#2What about wrapping nil in a Maybe or Option type?
Re: Excessive nil pointer checks in Go
#3This is good advice for humans: they can quantify to decide "too many nil checks" or not. But it's not good for agentic coding, which we're entering the age of. Although agents are the worst they'll ever be right now, they're never going to be great at quantifying too many nil checks. I think we'll have to get used to far more nil checks than even bad programmers put in. But that doesn't matter to agents, they've got infinite attention spans, no cognitive bias and large working memories. Sonn we'll see no nil checks.
Re: Excessive nil pointer checks in Go
#4Delegate all `nil` and bad input checks to a validation framework and use it in all your constructor functions.
Re: Excessive nil pointer checks in Go
#5What about wrapping nil in a Maybe or Option type?
This is more about a hard dependency which causes a function to early exit
Re: Excessive nil pointer checks in Go
#6What about wrapping nil in a Maybe or Option type?
In this case, the missing piece in Go is the NonNullable hint. That would make it clear that null checks aren't needed, enforceable by the type system, and lintable.
Option types just forces you to do the check, but doesn't remove the need for it.
Now that we have generic types, a NonNullable intrinsic type seems doable...
Re: Excessive nil pointer checks in Go
#7What about wrapping nil in a Maybe or Option type?
In this case, the missing piece in Go is the NonNullable hint. That would make it clear that null checks aren't needed, enforceable by the type system, and lintable. Option types just forces you to do the check, but doesn't remove the need for it. Now that we have generic types, a NonNullable intrinsic type seems doable...
References like C++, maybe?
Re: Excessive nil pointer checks in Go
#8Also known as contract programming vs. defensive programming. This argument is very old, is not specific to golang, and I have found myself on both sides at different points in my carreer.
Re: Excessive nil pointer checks in Go
#9This is the mess a language lands on when it conflates optionality (a semantic concept) with references/pointers (purely a machine concept). In Go, the requirement "need (non-optional) a reference to an object" is simply not expressible. This is a solved problem in other languages, for example `&T` vs. `Option` in Rust.
Re: Excessive nil pointer checks in Go
#10What about wrapping nil in a Maybe or Option type?
In this case, the missing piece in Go is the NonNullable hint. That would make it clear that null checks aren't needed, enforceable by the type system, and lintable. Option types just forces you to do the check, but doesn't remove the need for it. Now that we have generic types, a NonNullable intrinsic type seems doable...
Or a set theoretic type system with union type declarations (foo|null), like in TypeScript.