Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Excessive nil pointer checks in Go

konradreiche.com

Post reply on HN
Print view View original

81–90 of 116 posts

Re: Excessive nil pointer checks in Go

#81

Post by autarch »

edoceo wrote: post #74
liampulles wrote: post #71

At a previous job, we introduced a simple Optional generic type, with JSON implementation, and it pretty much solved uncertain nil issues. Sometimes the solution is simple and boring.

Doesn't this lead to an unstuctured data problem?

We've done the same thing in my job. I think what they're saying is that rather than passing/returning `SomeStruct` and having it maybe be optional, they either pass `SomeStruct`, with a rule that it's never nil, _or_ they pass `Option[*SomeStruct]`. Then anything that deals with optional types is forced to explicitly check.

This is exactly how Rust works, except there it's built into the compiler, and there's no such as nil in most code.

Re: Excessive nil pointer checks in Go

#82

Post by bvrmn »

uecker wrote: post #80
bvrmn wrote: post #78

Earlier quoted context omitted.

Yes it is. 1) Most of pointers in real apps are non-nullable and it's nice to have enforcement from a compiler. 2) Good compilers verify you actually check nullable (optional) values have a corresponding check. In particular Zig literally forces you to unwrap value, so no unexpected state. It's a really amazing QoL. And no, optionality doesn't make type system any harder. Also C lacks alignment enforcement on type le…

My worries about coding all these things into type systems is that this freezes the semantics at a time during development where one is still figuring out the ideal semantics. In any case, I wonder what you think about my experimental maybe type? https://godbolt.org/z/MTdj81841

I like maybe_value dereferences NULL with SIGILL and you have at least a backtrace with exact invalid access position.

Re: Excessive nil pointer checks in Go

#83

Post by andrewjf »

retrodaredevil wrote: post #68

The design of error handling in Go is interesting because they wanted to force people to actually handle errors by returning them as values, but then you as the programmer have to decide whether an error should be returned or a panic should be used. It reminds me of the original intention of checked exceptions in Java: checked exceptions are for things you force the caller to handle, unchecked exceptions are for "you…

But you don't have to handle errors in Go. With multi-return you just don't bother with the "err" value and happily proceed with whatever is in the first return position.

IMHO, only languages with exceptions or Sum types that encode that a return is either a value or an Err (but not both) actually do what Golang says it does (make you handle errors).

Re: Excessive nil pointer checks in Go

#84

Post by andrewjf »

guilhas wrote: post #54
nilirl wrote: post #34

Go is a very unique language in that it is the only language designed to make you understand the frustration of online dating. First, seduction, and then as it reveals how little it cares about you, eventual disappointment.

[flagged]

Rust tortures you into greatness.

Re: Excessive nil pointer checks in Go

#85

Post by uecker »

bvrmn wrote: post #82
uecker wrote: post #80

Earlier quoted context omitted.

My worries about coding all these things into type systems is that this freezes the semantics at a time during development where one is still figuring out the ideal semantics. In any case, I wonder what you think about my experimental maybe type? https://godbolt.org/z/MTdj81841

I like maybe_value dereferences NULL with SIGILL and you have at least a backtrace with exact invalid access position.

Oh, you can get the information at compile time as well. https://godbolt.org/z/hTYbTE8j8 (or https://godbolt.org/z/K1M68sY3Y but this will be tricky in a larger code base)

Re: Excessive nil pointer checks in Go

#86

Post by Fire-Dragon-DoL »

aatd86 wrote: post #62
Fire-Dragon-DoL wrote: post #15

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 w…

You are approaching the issue but from the other direction :) It is indeed subtle. It could be solvable though if someone wanted to change the current behavior, in a forward compatible way. Hint: "Don't use pointers at all" is the requirement that you would have to relax. That means that you cannot know whether a pointer is safe or not to be used from within an interface. Conservatively, that means that every nil poi…

That would be interesting.

Re: Excessive nil pointer checks in Go

#87

Post by jspdown »

I very much like Go's simplicity, but nils are terrible. Pointers carry 3 different intents that are not encoded in the code:

- Optionality

- Mutability

- Memory optimisation

I agree with the author that when the pointer is here for mutability or to limit copies you need to check nullity at the outer layer. But for optionality you need to check it each time you access that value.

Sometimes the intent is not clear and you are forced to check nullity everywhere. An Option type fixes this but it's not idiomatic Go code and forces to wrap every thing you call

Re: Excessive nil pointer checks in Go

#88

Post by trallnag »

guilhas wrote: post #54
nilirl wrote: post #34

Go is a very unique language in that it is the only language designed to make you understand the frustration of online dating. First, seduction, and then as it reveals how little it cares about you, eventual disappointment.

[flagged]

[flagged]

Re: Excessive nil pointer checks in Go

#90

Post by carmly56 »

Zambyte wrote: post #65
mirekrusin wrote: post #25

Earlier quoted context omitted.

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…

> They need Go 2 with T and ? T - that would be nice language to use. Zig has basically been this to me. As a developer, writing Zig feels a lot like writing Go, except with basically all of the pain points addressed. - Zig has different pointer types for different things. The default pointer type points to exactly one value. It also has an optional pointer type as described. Arrays and slices are also pointers of so…

I really like Zig, but the lack of easy to use interfaces is kind of a dealbreaker for me. One issue but I can't look past it when building anything of substantial size.
Post reply on HN