3 ms·

> Of course I'm joking, but I think implicit nullability is the worst part of Go. Go doesn't have implicit nullability. You have to declare that something is a

> Of course I'm joking, but I think implicit nullability is the worst part of Go. Go doesn't have implicit nullability. You have to declare that something is a pointer for it to be nullable. There are a few kinds of pointers: "normal" pointers, slices, maps, function pointers, and interfaces. Any of those pointer types are nilable. Regular structs and primitives are not nilable. var x someStruct = nil //this will not compile var x int = nil //this also won't compile

cies 6y ago
When i read Go code it is riddled with null guards. Any of those null guards may be removed, code compiles without additional warnings but now may blow up at runtime. Sorry, but to me that's a clear symptom of implicit nullability. Edit: clarification, to me it does not show in the type signature that something may return a null, also I do not have to unpack a possible null value (like with Maybe or Option).
- coder543 6y ago
  You can't check for nil on something that isn't nilable -- it's a compile error to do so in Go. Your definition of "implicit nullability" is suspect here. Go doesn't even implicitly de-reference things, which is what I think you're intending to say that it does. (EDIT: field access does cause a dereference, as was pointed out in a response to this comment. I still think of this as an explicit action when you're specifically operating on a pointer variable, but I'll concede this point here.) Your position on this is really confusing at the moment. Go handles nullability in an extremely different way from Java. Edit for your edit: > clarification, to me it does not show in the type signature that something may return a null The best way to know something won't be null is to use value types where possible. Don't return nilable values unless you have a good reason. When you return nilable values, only return nil when the error value isn't nil. This is a common pattern in Go code. Why would you return nil if there wasn't an error? If there was an error, why would you care what else was returned, outside of some very exceptional circumstances? > also I do not have to unpack a possible null value (like with Maybe or Option). I write Rust and Go professionally... I'm familiar with the pros and cons here, and I wish that Go would adopt Sum Types, but this has nothing to do with "implicit nullability", and in practice... it's really not a big deal. I've written huge amounts of Go code, and I just don't remember encountering nil exceptions in production except once in a blue moon -- and it is similarly common in Rust to hit an "expect" or "unwrap" that you thought was statically impossible to reach. Go has good editors (like GoLand) and linters (like golangci-lint) that make it easy to avoid most of the practical pitfalls.
  - shric 6y ago
    > Go doesn't even implicitly de-reference things Except when accessing a field via a pointer to struct. https://tour.golang.org/moretypes/4 https://tour.golang.org/moretypes/4
    - deleted 6y ago
      [deleted]
  - cies 6y ago
    > I wish that Go would adopt Sum Types And then make a Maybe sum type? But then it is too late as the std lib communicates with nils instead of Maybes > The best way to know something won't be null is to use value types where possible. Don't return nilable values unless you have a good reason. I'm not doing this, I'm using an API that does! I cannot choose what some code returns, all I can do is --sigh-- add another null guard. If it is my discipline to add null guards or have runtime explosions I consider the nulls to be implicit. That you find as much runtime problems with unwrap/expect in Rust (which have a lot of red tape on them in API docs) as with "missing null guards" in Go, is great for you, but to me that does not make it a good design choice in Go.
    - coder543 6y ago
      > If it is my discipline to add null guards or have runtime explosions I consider the nulls to be implicit. But they're still explicit nulls. You seem to be saying that only implicit nulls require null guards, but that's just not what that means (as far as I have learned). You seem to hate nullability as a concept, which is fine, but that's different from hating implicit nullability. > That you find as much runtime problems with unwrap/expect in Rust (which have a lot of red tape on them in API docs) as with "missing null guards" in Go, is great for you, but to me that does not make it a good design choice in Go. It's also a comment on how NPEs are just not a common hazard in Go compared to my past experiences with Java, especially when combined with good editors and linters.
      - wtetzner 6y ago
creata 6y ago
I don't like your definition of "implicit nullability". Following that logic, Java integers can't be null either, and C has no implicit nullability! In practice, when we say we don't want implicit nullability, we mean that we want nonnullable everything, including pointers. After all, Tony Hoare called null references his billion dollar mistake.
- coder543 6y ago
  That's not implicit nullability, in my opinion. I agree that non-nullable references are wonderful, and Go will probably have to grapple with that eventually. I just don't want people to get the wrong idea. Go has value types -- not everything is a reference that is implicitly nullable. C isn't implicitly nullable, you are correct.
  - creata 6y ago
    I feel like we're just using different definitions of implicit nullability, and by your definition, no language with value types is implicitly nullable, whereas by my definition, every language without nullable references is implicitly nullable. I think your definition is bad and uncommon, but that's not a very fruitful line of discussion.
    - coder543 6y ago
      You're referring to how some languages have non-nullable references, which is fine. That's probably a better term to be using, since it is more clearly defined and less contentious in this discussion. I agree that Go should consider adopting non-nullable references.
- cies 6y ago
  If I return a struct pointer in C, I can also return null. The return type does not communicate this to me: this is what I call implicit nullability. It is just a bad contract, as it is often misunderstood, and it allow for runtime errors that could easily have been caught at compile time.

cies 6y ago

When i read Go code it is riddled with null guards. Any of those null guards may be removed, code compiles without additional warnings but now may blow up at runtime. Sorry, but to me that's a clear symptom of implicit nullability. Edit: clarification, to me it does not show in the type signature that something may return a null, also I do not have to unpack a possible null value (like with Maybe or Option).

coder543 6y ago
You can't check for nil on something that isn't nilable -- it's a compile error to do so in Go. Your definition of "implicit nullability" is suspect here. Go doesn't even implicitly de-reference things, which is what I think you're intending to say that it does. (EDIT: field access does cause a dereference, as was pointed out in a response to this comment. I still think of this as an explicit action when you're specifically operating on a pointer variable, but I'll concede this point here.) Your position on this is really confusing at the moment. Go handles nullability in an extremely different way from Java. Edit for your edit: > clarification, to me it does not show in the type signature that something may return a null The best way to know something won't be null is to use value types where possible. Don't return nilable values unless you have a good reason. When you return nilable values, only return nil when the error value isn't nil. This is a common pattern in Go code. Why would you return nil if there wasn't an error? If there was an error, why would you care what else was returned, outside of some very exceptional circumstances? > also I do not have to unpack a possible null value (like with Maybe or Option). I write Rust and Go professionally... I'm familiar with the pros and cons here, and I wish that Go would adopt Sum Types, but this has nothing to do with "implicit nullability", and in practice... it's really not a big deal. I've written huge amounts of Go code, and I just don't remember encountering nil exceptions in production except once in a blue moon -- and it is similarly common in Rust to hit an "expect" or "unwrap" that you thought was statically impossible to reach. Go has good editors (like GoLand) and linters (like golangci-lint) that make it easy to avoid most of the practical pitfalls.
- shric 6y ago
  > Go doesn't even implicitly de-reference things Except when accessing a field via a pointer to struct. https://tour.golang.org/moretypes/4 https://tour.golang.org/moretypes/4
  - deleted 6y ago
    [deleted]
- cies 6y ago
  > I wish that Go would adopt Sum Types And then make a Maybe sum type? But then it is too late as the std lib communicates with nils instead of Maybes > The best way to know something won't be null is to use value types where possible. Don't return nilable values unless you have a good reason. I'm not doing this, I'm using an API that does! I cannot choose what some code returns, all I can do is --sigh-- add another null guard. If it is my discipline to add null guards or have runtime explosions I consider the nulls to be implicit. That you find as much runtime problems with unwrap/expect in Rust (which have a lot of red tape on them in API docs) as with "missing null guards" in Go, is great for you, but to me that does not make it a good design choice in Go.
  - coder543 6y ago
    > If it is my discipline to add null guards or have runtime explosions I consider the nulls to be implicit. But they're still explicit nulls. You seem to be saying that only implicit nulls require null guards, but that's just not what that means (as far as I have learned). You seem to hate nullability as a concept, which is fine, but that's different from hating implicit nullability. > That you find as much runtime problems with unwrap/expect in Rust (which have a lot of red tape on them in API docs) as with "missing null guards" in Go, is great for you, but to me that does not make it a good design choice in Go. It's also a comment on how NPEs are just not a common hazard in Go compared to my past experiences with Java, especially when combined with good editors and linters.
    - wtetzner 6y ago

creata 6y ago

I don't like your definition of "implicit nullability". Following that logic, Java integers can't be null either, and C has no implicit nullability! In practice, when we say we don't want implicit nullability, we mean that we want nonnullable everything, including pointers. After all, Tony Hoare called null references his billion dollar mistake.

coder543 6y ago
That's not implicit nullability, in my opinion. I agree that non-nullable references are wonderful, and Go will probably have to grapple with that eventually. I just don't want people to get the wrong idea. Go has value types -- not everything is a reference that is implicitly nullable. C isn't implicitly nullable, you are correct.
- creata 6y ago
  I feel like we're just using different definitions of implicit nullability, and by your definition, no language with value types is implicitly nullable, whereas by my definition, every language without nullable references is implicitly nullable. I think your definition is bad and uncommon, but that's not a very fruitful line of discussion.
  - coder543 6y ago
    You're referring to how some languages have non-nullable references, which is fine. That's probably a better term to be using, since it is more clearly defined and less contentious in this discussion. I agree that Go should consider adopting non-nullable references.
cies 6y ago
If I return a struct pointer in C, I can also return null. The return type does not communicate this to me: this is what I call implicit nullability. It is just a bad contract, as it is often misunderstood, and it allow for runtime errors that could easily have been caught at compile time.