3 ms·

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 wh

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.

ok_dad 4y ago
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.
- masklinn 4y ago
  > 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.
  - convolvatron 4y ago
    does anyone else think Go would be a much better language without the pointer distinction? maybe an explicit mutable type modifier instead?
    - ok_dad 4y ago
      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.
  - ok_dad 4y ago
    That's one of the most annoying things to me coming from Python: the inability to have a default argument value.
  - ecnahc515 4y ago
    Go can use escape analysis to determine if a heap allocation is actually required in some cases.
the_gipsy 4y ago
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.
jerf 4y ago
"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.
- ok_dad 4y ago
  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"?
  - masklinn 4y ago
    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.
- 4y ago

ok_dad 4y ago

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.

masklinn 4y ago
> 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.
- convolvatron 4y ago
  does anyone else think Go would be a much better language without the pointer distinction? maybe an explicit mutable type modifier instead?
  - ok_dad 4y ago
    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.
- ok_dad 4y ago
  That's one of the most annoying things to me coming from Python: the inability to have a default argument value.
- ecnahc515 4y ago
  Go can use escape analysis to determine if a heap allocation is actually required in some cases.

the_gipsy 4y ago

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.

jerf 4y ago

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

ok_dad 4y ago
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"?
- masklinn 4y ago
  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.
4y ago