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.
Re:Things Go needs more than generics
by tsimionescu on Monday October 04, 2021 @03:37AM
(#28744124)
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.
Re:Things Go needs more than generics
by tsimionescu on Monday October 04, 2021 @05:06AM
(#28744632)
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.
I have no idea what you mean.
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).