3 ms·

> 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 b

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

by cies 6y ago

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.