Hacker News Reader

Comment by tsimionescu | Hacker News Reader

> With Go, you have to check for nil in every function even if all your callers already check for nil. That's because Go can't declare a function's arg as non-nullable type.

I have no idea what you mean.

  func foo(a int, b someStruct, c *someStruct)

a and b can't be nil, c can.

Now, it is true that there are multiple reasons for using a pointer aside from supporting nil (ability to modify, optimization not to copy a huge object).

View on HN

I'm not who you're responding to, but the fact that interfaces/pointers (among other things) are nullable and there is no way to make them non-nullable is a problem with Go. A lot of bugs in Go programs are due to calling methods on those types and getting a null pointer error.

Your claims are correct, but it feels like you're missing the point they are (ineffectively) making.

Sure, that is why I added my second paragraph recognizing that things aren't all great, but still Go is a little better than Java for example in this area, where literally every non-primitive type is nullable.

Aren't you proving his point? You cannot mark c as non-nil.

Yes, but still a and b are non-nil. My point was that Go is not like Java, where literally all non-primitive types are nullable.

What if I want to pass a pointer into the function (maybe I want to mutate the object), but I want that pointer to be non-nil?

You make it seem like value types solve this problem, but they don't. C also has the same thing you're talking about, but it still has nullability problems.

I think other comments are not even asking for anything complex. Something akin to C++'s references (which cannot be null) would already be a step forward.

I was only talking about pointers and interfaces, not primitive types. Yes A and B can't be nil, but I was only talking about C. Pointers (C) are what cause crashes in Go programs when using them without checking if they're nil first.

Reply on news.ycombinator.com