What I like about Go

I'd rather have the insights of someone who programmed in one language, than someone who dabbled in 200.

The line has definitely moved but not so far that Go would be considered low level. I think most people would consider languages without any sort of garbage collection to be "low level" now so C, C++, Rust, etc.

Go used to (still?) market itself as a "systems programming language" and I think that along with the presence of pointer syntax gives some the initial impression that Go is a scary low level language.

In fairness to the author of this article, he did call it low level as a comparison to Python and mentioned that it not as low level as C which is all true.

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.

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.

>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.

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.

It is incredible to watch how something that exists since compiled languages are a thing, is so appreciated as it was invented yesterday.

This blog post could have been written by me. This is exactly how I feel, on all accounts.

Hope this doesn't mean we are in a cult ;)

I'm new to Go within the past year or so. Every time I start thinking about some fancy sugar I got from another language, I've basically realized that I didn't need it. The ease of "build" and "run" is amazing to me, and when I find I need to do something fancy in my code, I generally find that I don't actually need that.