5 ms·

I too find it annoying in Go, though I'm not sure what the default value of a reference in a struct would be otherwise. However, I do see the value of NULL in

by biztos 10y ago

I too find it annoying in Go, though I'm not sure what the default value of a reference in a struct would be otherwise. However, I do see the value of NULL in a database context even though it makes database interfaces harder -- especially in Go, where the standard marshaling paradigm means anything NULLable has to be a reference and thus have a nil-check every time it's used. The conceptual match is so awkward that when I write anything database-related for Go, if I have the option then at the same time I make everything in the database NOT NULL; even though that screws with the database. Ah, NULL. When I think about the pain it causes, balanced against its utility, I sometimes wish I'd never heard of it. And I'm sure learned people said the same thing about Zero, once upon a time.

TylerE 10y ago
What's wrong with using an Option/Maybe type? Can't Go do that?
- cyphar 10y ago
  You could (just use an interface). However, it would be a pain to use because Go doesn't have generics (if a type X implements the Maybe interface, it is not true that []X can be casted to []Maybe). So you would have to always make temporary slices to copy all of your Xs into.
- brobinson 10y ago
  Go effectively has Option types for database query results: https://golang.org/pkg/database/sql/#NullBool https://golang.org/pkg/database/sql/#NullBool
  - unscaled 10y ago
    This is not a generic option type, but rather a tri-state bool, or an Option<bool>. Go has no user-defined generics, so you can't have a bool type. It does have built-in "magical" generics, namely arrays, slices maps and channels, but no option/maybes. Language-level option types are not unheard of (C#, Swift and Kotlin all have a notion of this sort, although they all support proper user-defined generics as well).
    - masklinn 10y ago
      > Language-level option types are not unheard of (C#, Swift and Kotlin all have a notion of this sort) Swift's Optional is a library type: https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L122 https://github.com/apple/swift/blob/master/stdlib/public/cor... Though the compiler is aware of it and it does have language-level support (nil, !, ?, if let)
simcop2387 10y ago
> I too find it annoying in Go, though I'm not sure what the default value of a reference in a struct would be otherwise. The way it works in Rust is that you can't have a reference without the thing you're referring to. There isn't a default value and because of that it's an error to try to have a reference without something to refer to. The way Rust works with this is to have a type called Option (I think this is a monad in haskell?) that lets you say this can be None or Some, so you have to explicitly handle the None case whenever you use it (either by panicing, or matching or some other method).
- gbacon 10y ago
  You’re thinking of Maybe[1]: data Maybe a = Just a | Nothing deriving (Eq, Ord) Yes, it is a monad[2]. return :: a -> Maybe a return x = Just x (>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b (>>=) m g = case m of Nothing -> Nothing Just x -> g x [1]: https://wiki.haskell.org/Maybe https://wiki.haskell.org/Maybe [2]: https://en.wikibooks.org/wiki/Haskell/Understanding_monads/Maybe https://en.wikibooks.org/wiki/Haskell/Understanding_monads/M...
  - aweinstock 10y ago
    It's a monad in Rust too (with Some being return, and and_then[1] being >>=). Rust's generics just aren't yet[2] flexible enough to abstract over monads within the language. [1] https://doc.rust-lang.org/std/option/enum.Option.html#method.and_then https://doc.rust-lang.org/std/option/enum.Option.html#method... [2] https://github.com/rust-lang/rfcs/issues/324 https://github.com/rust-lang/rfcs/issues/324
  - merijnv 10y ago
    Option (and/or option) is the usual name of Maybe in ML style languages like SML, ocaml, etc.
  - IanCal 10y ago
    For anyone who has the same reaction as I did when first hearing of this, "But isn't that just like a nullable value?" (don't worry, this post will not contain any monad analogies) Yes. Ish. In languages that have a null/nil/None then almost anything you have passed to any function could be null. Every function you write could have a null passed into it and you either have to do checks on everything or trust that other people will never pass those values in. That's pretty OK until something unexpectedly receives one and hands it off to another function that doesn't deal with it gracefully. In Haskell (and I assume others) this can only happen to Maybe types, they're the only ones that can have the value of Nothing. So the compiler knows which things can and cannot be Nothing, and therefore can throw an error on compilation if you are trying to pass a Maybe String (something that can be either a "Just String" that you can get a String from or a Nothing) into a function which only understands how to process a String. This feels like it might be restrictive, but there are generic functions you can use to take functions which only understand how to process a String and turn it into one that handles a Maybe. It's quite a nice system, even though I get flashbacks to java complaining I haven't dealt with all the exceptions. Haskell doesn't completely stop you from shooting yourself in the foot though, you can still ask for an item from an empty list and break things. There are interesting approaches to problems like that however: http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/ http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/ Finally, it's worth pointing out that Maybe and Nothing and Just and all that aren't built into the language, they're defined using the code that gbacon wrote. So in a way, Haskell doesn't have a Maybe type, people have written types that work really well for this kind of problem and everyone uses it because it's so useful. [disclaimer: I've probably written 'function', 'type', 'value' and other terms with quite specific meanings in a very general way. Apologies if this hurts the understanding, and I would appreciate corrections if that's the case, but just assume I'm not being too precise if things don't make sense]
unscaled 10y ago
Go's wholesale embrace of null is kinda jarring at this day and age, since it doesn't even have safe null dereferencing operators like Groovy, C#, Kotlin et. al. It's like Java all over again. Considering Rob Pike is a huge fan of Tony Hoare, and the inevitable mountain of pain caused by null references, that's kinda surprising. But I guess "Worse is Better" in the sense of "simplicity of implementation is valued over all else" is still the guiding principle of Go. As Tony Hoare himself said: "But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement". It seems like we're doomed to repeating this mistake again and again.

by biztos 10y ago

TylerE 10y ago

What's wrong with using an Option/Maybe type? Can't Go do that?

cyphar 10y ago
You could (just use an interface). However, it would be a pain to use because Go doesn't have generics (if a type X implements the Maybe interface, it is not true that []X can be casted to []Maybe). So you would have to always make temporary slices to copy all of your Xs into.
brobinson 10y ago
Go effectively has Option types for database query results: https://golang.org/pkg/database/sql/#NullBool https://golang.org/pkg/database/sql/#NullBool
- unscaled 10y ago
  This is not a generic option type, but rather a tri-state bool, or an Option<bool>. Go has no user-defined generics, so you can't have a bool type. It does have built-in "magical" generics, namely arrays, slices maps and channels, but no option/maybes. Language-level option types are not unheard of (C#, Swift and Kotlin all have a notion of this sort, although they all support proper user-defined generics as well).
  - masklinn 10y ago
    > Language-level option types are not unheard of (C#, Swift and Kotlin all have a notion of this sort) Swift's Optional is a library type: https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L122 https://github.com/apple/swift/blob/master/stdlib/public/cor... Though the compiler is aware of it and it does have language-level support (nil, !, ?, if let)

simcop2387 10y ago

> I too find it annoying in Go, though I'm not sure what the default value of a reference in a struct would be otherwise. The way it works in Rust is that you can't have a reference without the thing you're referring to. There isn't a default value and because of that it's an error to try to have a reference without something to refer to. The way Rust works with this is to have a type called Option (I think this is a monad in haskell?) that lets you say this can be None or Some, so you have to explicitly handle the None case whenever you use it (either by panicing, or matching or some other method).

gbacon 10y ago
You’re thinking of Maybe[1]: data Maybe a = Just a | Nothing deriving (Eq, Ord) Yes, it is a monad[2]. return :: a -> Maybe a return x = Just x (>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b (>>=) m g = case m of Nothing -> Nothing Just x -> g x [1]: https://wiki.haskell.org/Maybe https://wiki.haskell.org/Maybe [2]: https://en.wikibooks.org/wiki/Haskell/Understanding_monads/Maybe https://en.wikibooks.org/wiki/Haskell/Understanding_monads/M...
- aweinstock 10y ago
  It's a monad in Rust too (with Some being return, and and_then[1] being >>=). Rust's generics just aren't yet[2] flexible enough to abstract over monads within the language. [1] https://doc.rust-lang.org/std/option/enum.Option.html#method.and_then https://doc.rust-lang.org/std/option/enum.Option.html#method... [2] https://github.com/rust-lang/rfcs/issues/324 https://github.com/rust-lang/rfcs/issues/324
- merijnv 10y ago
  Option (and/or option) is the usual name of Maybe in ML style languages like SML, ocaml, etc.
- IanCal 10y ago
  For anyone who has the same reaction as I did when first hearing of this, "But isn't that just like a nullable value?" (don't worry, this post will not contain any monad analogies) Yes. Ish. In languages that have a null/nil/None then almost anything you have passed to any function could be null. Every function you write could have a null passed into it and you either have to do checks on everything or trust that other people will never pass those values in. That's pretty OK until something unexpectedly receives one and hands it off to another function that doesn't deal with it gracefully. In Haskell (and I assume others) this can only happen to Maybe types, they're the only ones that can have the value of Nothing. So the compiler knows which things can and cannot be Nothing, and therefore can throw an error on compilation if you are trying to pass a Maybe String (something that can be either a "Just String" that you can get a String from or a Nothing) into a function which only understands how to process a String. This feels like it might be restrictive, but there are generic functions you can use to take functions which only understand how to process a String and turn it into one that handles a Maybe. It's quite a nice system, even though I get flashbacks to java complaining I haven't dealt with all the exceptions. Haskell doesn't completely stop you from shooting yourself in the foot though, you can still ask for an item from an empty list and break things. There are interesting approaches to problems like that however: http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/ http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/ Finally, it's worth pointing out that Maybe and Nothing and Just and all that aren't built into the language, they're defined using the code that gbacon wrote. So in a way, Haskell doesn't have a Maybe type, people have written types that work really well for this kind of problem and everyone uses it because it's so useful. [disclaimer: I've probably written 'function', 'type', 'value' and other terms with quite specific meanings in a very general way. Apologies if this hurts the understanding, and I would appreciate corrections if that's the case, but just assume I'm not being too precise if things don't make sense]

unscaled 10y ago

Go's wholesale embrace of null is kinda jarring at this day and age, since it doesn't even have safe null dereferencing operators like Groovy, C#, Kotlin et. al. It's like Java all over again. Considering Rob Pike is a huge fan of Tony Hoare, and the inevitable mountain of pain caused by null references, that's kinda surprising. But I guess "Worse is Better" in the sense of "simplicity of implementation is valued over all else" is still the guiding principle of Go. As Tony Hoare himself said: "But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement". It seems like we're doomed to repeating this mistake again and again.