4 ms·

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

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
    > But they're still explicit nulls. Except that there may be other reasons to use pointers than just nullability. And in that case, there's no mechanism to specify whether or not the thing being pointed to is nullable. I think that's where the implicitness in question comes in.
  - cies 6y ago
    Explicit to me is when I can see from the return type it is or isnt nullable AND that i have to deal with the null case explicitly (so nullableUser.lastName() errors out as I cannot call lastName() on null). But I might well be mistaken.

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
  > But they're still explicit nulls. Except that there may be other reasons to use pointers than just nullability. And in that case, there's no mechanism to specify whether or not the thing being pointed to is nullable. I think that's where the implicitness in question comes in.
- cies 6y ago
  Explicit to me is when I can see from the return type it is or isnt nullable AND that i have to deal with the null case explicitly (so nullableUser.lastName() errors out as I cannot call lastName() on null). But I might well be mistaken.