Hacker News Reader

Comment by wrcwill | Hacker News Reader

question for experienced go devs: how do you deal with the lack of optional type or narrowing?

from what i understand, pointers become used for that purpose instead (in addition to mutability). which then means that when you get a pointer you don’t know for what reason it is used, so you have to check it even if it was checked higher up in the callstack already.

i wouldn’t actually mind the fact that you can forget to check for nil, i can accept a panic here and there, pretty simple to fix..

the issue i am finding is that it "pollutes" the code, since you end up doing the check more than once for the same value.

if atleast you could only check once and then the compiler would know (ie optionals, or narrowing like TS). ideally you would dereference after the check, but you can’t because pointers are used for mutability AND optionals

in other words, are there any tricks so that you only have to check once?

View on HN

Soon after generics were introduced, I put a generic Maybe type in our team's codebase. Its been very helpful.

Other than that though, I would say pointers are a last resort for indicating optional (I certainly do use them for this, but uncommonly). Idiomatic Go I think would suggest you use the empty value (I would use an empty value plus an // Optional comment).

Using pointers in general is fairly uncommon in the Go code I write - I don't often need the mutability as you say, because I try to stick to pure functions.

My thinking also, regardless of the language: be suspicious of a function that accepts an optional type. One should ask: is there a non short-circuit or non-error path in the empty case? If not, don't pass an optional, unwrap up the chain. Even if there is a valid path for an empty value, perhaps ask if the function should be split into two cleaner functions.

Check it once and type cast it before passing it down the call stack. If you need a polymorphic type all the way down then model it using structs and interfaces so that the required operations are always available as methods. It’s the same as other languages which lack optionals/narrowing: C/C++, Java, etc.

sorry, type cast it to what?

Say i have `*Thing`. Are you saying i should cast it to a `Thing`? That is what I was doing initially (im fine with copies), but then you can't call functions that mutate.

C++ and Java both have some form of Optional btw.

Yes, but in both it's not really mainstream.

>question for experienced go devs: how do you deal with the lack of optional type

Perhaps they're used to use, as most mainstream languages didn't use to have it and many still don't (or just have it as a seldom used afterthought, like Java)?

> how do you deal with the lack of optional type or narrowing?

The idiomatic way is to return an error or an `ok` boolean at the function boundary. Callers always check return value anyway, this is hard to forget because it’s almost always needed anyway.

The type itself can be value or pointer – its an orthogonal choice. If you have a value type that you return, then you should return the zero value (for instance `time.Time{}`. Both nil and the zero type are comparable by equality check.

This is not ideal, and gets messy when the zero type is a valid value for instance. Generics offer some hope but they are not as capable as in eg Rust.

yeah, is there a way to deserialize using (val, err) instead of *val when the field is optional?

Hmm, are we talking json parsing? Yes, the field would take the zero value. If you need to differentiate between the zero-value (eg empty string, 0 for numbers) you’d typically use a pointer only for that purpose. That kinda sucks but there are some good arguments for zero-defaults too.

The unmarshal functions take a reference but they don’t need to be declared as (heap-based) pointers. You can pass a `&val` directly. It needs a reference passed in to determine the type.

Just for curiosity's sake, what good arguments for zero-defaults exist?

yeah i meant if each field could be a tuple of (val, bool) or (val, err) to get around the pointer issue

There are no tuples in Go. Very unfortunate. Tuples, enums and pattern matching is sooo good in Rust. I really miss it in Go.

In many cases, you don’t really need to check pointers unless you specifically want to handle the nil case. Go’s panic / recover feature lets you “catch” nil pointer access elsewhere. For instance, if you have an HTTP handler, it’s way easy to install a middleware that recovers from panics than it is to check for nil everywhere.

The point of having it in the type system is not just to force you to check it. It is also to clearly document where you need to check it, and just as important, where you don't.

Without it, you don't have that "this is guaranteed to exist at this point" indication that can actually reduce the overall number of checks in practice.

I get what you’re saying, but it just rarely turns out to be an issue in Go. Not sure why.

Reply on news.ycombinator.com