Hacker News Reader

The real problem is that they imported the concept of null/nil being a value of every type from C. Null/nil is fine (although Option/Optional/Maybe is better when you want to nest), but it should be an opt-in part of the type such that it is a compile time error to assign a null/nil value to a variable unless it's the nullable variant of the type.

Actually, not all Go types are nilable. Integers and strings; those things aren’t nilable. Pointers, interfaces, slices, and some other stuff is. I’m new to Go so I don’t remember the rules exactly, but you can look up the exact details I’m sure.

> Integers and strings; those things aren’t nilable.

Which is then annoying because if you want an optional integer you now need a pointer, and a heap allocation.

does anyone else think Go would be a much better language without the pointer distinction? maybe an explicit mutable type modifier instead?

Yea, I think references to other values should be a type, like a `Reference[T]`. Then you can pass something by reference, rather than value, without having confusing referencing/dereferencing. A `Reference[T]` could have some sort of element reflection, where you can just use it like it's a `T`.

Pointers, referencing, dereferencing; that can get confusing even for skilled engineers.

That's one of the most annoying things to me coming from Python: the inability to have a default argument value.

Go can use escape analysis to determine if a heap allocation is actually required in some cases.

Pointers are conflated with Option-types in go. Understandably, because go wants to be as simple as possible, has those nasty zero-values as "solution", had no generics for a long time, and will probably never have sum-types.

So, guess if it's a pointer or an Option, and hope that your peers guess the same.

"The real problem is that they imported the concept of null/nil being a value of every type from C."

While I agree that's a problem, it's mostly a separate problem to the nil interface vs. interface containing a nil. The "nilness" provides a cognitively-convenient hook, especially with the attractive nuisance of the whole issue of nil/null in general, but the root cause of this particular issue is really "putting things into interfaces that don't fulfill the contract of the interface", which as I show in my post, doesn't require a nil anywhere in sight to do it.

When you stop doing that, this whole interface nil vs. containing a nil problem goes away. Basically, in Go code, you should never be trying to penetrate an interface value to see if it contains a nil. If you're doing that, the error occurred when the value you are examining was created, not at the point of use.

In fact, stop putting values that can't implement interface contracts into interface values and other code issues just go away, too. Not just in Go, either. Most large dynamically-typed language programs I've ever worked in are also shot through with this exact issue, it's just less visible because the compiler doesn't help you with the interfaces. They're still there, though. Just in the dark.

Even as a beginner in Go, I somehow internalized that if you want a value to be `nil`, use a "bare `nil`" rather than a concrete value initialized to `nil`. I don't know why you would want to initialize something on the heap, like in the article, if you didn't plan to use it later. Maybe in the most extreme case you might want to prepare an error object before the processing occurs, but even then I have never seen any Go tutorial that didn't return a "bare `nil`" for the `(err error)` return value if there was no error being returned. I guess people coming to Go from other languages sometimes don't look at the tutorials, or perhaps don't try and understand the language's "best practices"?

In real code, the problem would usually occur not because you want a value to be nil but because you’re converting a value you already have to an interface. And that value happened to be a pointer which is nil.

Arguably the most common line of code in Go, ‘if err != nil’ is doing what you’re saying you should never do in the language: check if an interface value is nil. (And, in fact, care must be taken when returning custom error types precisely because of the typed nil issue.)

So I don’t think the authors of the language see it the same way you do.

(FWIW I was also a Go style reviewer working with the Go team for a few years, and I’ve never heard this idea from them in that time.)

> In reality, once you understand this issue correctly, it essentially dissolves simply because you have the correct understanding.

When you understand something then you don’t have a problem understanding it any more.

He's saying theres a simple mental model where this all makes sense. That's not always the case, despite your implication.

So can you define what it is, beyond "not like a C void pointer"?

Because effectively, basic pointer behavior (nil check) is dangerously (panics) different depending on returning a nil interface or nil *struct (both are interchangeable).

Granted, I don't run into this problem every day, but it's not due to "understanding the issue correctly".

> C, where void pointers are all 0

I think you mean "null pointers are all 0". void pointers are something entirely different, and certainly not always 0.