3 ms·

I think nil is in the language because it keeps the compiler simpler than if it had to support an extra construct that exhausts the variants of option and resul

by t8sr 3y ago

I think nil is in the language because it keeps the compiler simpler than if it had to support an extra construct that exhausts the variants of option and result. In principle, you could implement a check, e.g. in govet, that tries to prove a value can't be nil and, if it can't, requires a runtime check. This is how things work, e.g., in eBPF, and it's fine. What really irks me about nil is that it's typed, and the (runtime!) type is part of the comparison. So checking "err == nil" can return false in case of "nil == nil" if you ever return a concrete error type rather than the interface. Now that is some crazy nonsense, and probably unfixable at this point.

jen20 3y ago
It defers a tiny piece of complexity in the language to every program written in the language (at least, ones that care about correctness).
- t8sr 3y ago
  Well, actually I think once you decide that any nilable type has to be so annotated (e.g. as an option type), that changes the language quite a bit. I’m not so sure there is any evidence that programs written in such languages are simpler. In my experience, e.g. Rust and C# programs tend to be more complex than Go programs. Of course you might say the opposite, my point is that there’s no real evidence in either direction. And dealing with such type annotation is much more than a tiny bit complex. Constructs usually used for this tend to be some of the most complicated things in any language that has them. (Rust’s match alone might even have more grammar to it than all of Go). Finally correctness gets thrown around a lot, but what does it mean? Disallowing nils isn’t a magic bullet, in fact in most practical programs I’ve seen, values where the option wrapper is empty panic anyway. And even if you could eliminate all null pointer errors, how big a win is that really for correctness? I haven’t seen a null dereference error in Go code in a while.
  - baq 3y ago
    Match is needed for sum types only for syntactic convenience; typescript does well without matching. In case of option/result a single if/else is basically the same as if err == nil… I’m sure an ergonomic syntax could be found.

by t8sr 3y ago

jen20 3y ago

It defers a tiny piece of complexity in the language to every program written in the language (at least, ones that care about correctness).

t8sr 3y ago
Well, actually I think once you decide that any nilable type has to be so annotated (e.g. as an option type), that changes the language quite a bit. I’m not so sure there is any evidence that programs written in such languages are simpler. In my experience, e.g. Rust and C# programs tend to be more complex than Go programs. Of course you might say the opposite, my point is that there’s no real evidence in either direction. And dealing with such type annotation is much more than a tiny bit complex. Constructs usually used for this tend to be some of the most complicated things in any language that has them. (Rust’s match alone might even have more grammar to it than all of Go). Finally correctness gets thrown around a lot, but what does it mean? Disallowing nils isn’t a magic bullet, in fact in most practical programs I’ve seen, values where the option wrapper is empty panic anyway. And even if you could eliminate all null pointer errors, how big a win is that really for correctness? I haven’t seen a null dereference error in Go code in a while.
- baq 3y ago
  Match is needed for sum types only for syntactic convenience; typescript does well without matching. In case of option/result a single if/else is basically the same as if err == nil… I’m sure an ergonomic syntax could be found.