3 ms·

"maybe" (Haskell) or "option" (Rust) types (other languages have them, too) are not zero value types. Option, for example, can be one of two types. Something

"maybe" (Haskell) or "option" (Rust) types (other languages have them, too) are not zero value types. Option, for example, can be one of two types. Something or Nothing. And if the Option is Something, then the value is embedded in the "Something" variant of the type. The callee has to match on the variant to extract the value. This provides more safety than nil does because you must specifically extract the value from the "Something" variant (and that extracted value can never be nil). You cannot extract the value from the "Nothing" variant (compiler error). So therefore, calling a function that takes an Option, and specifying Nothing is equivalent to nil (expresses intent to provide no value) with greater safety.

silisili 5y ago
I appreciate the thought out response, but do understand the concept. It just changes the onus somewhat. A well written Go program will check for and handle nil up front. That an option type is 'safer' only helps enforce good habits. I'm not against the idea, I just don't see the big benefit to a programmer who understands what he or she is working with. Unless the value is solely not having to think about nil cases, in which case I'd argue the value is very little.
- andrewjf 5y ago
  Relying on “well written” to prevent bugs is just a fantasy. Non-nullable types and compiler enforced checking of present/non-present values leads to more readable and more maintainable code. And there’s a mountain of CVEs, and bugs in go programs, to prove it. Maybe you just have to experience it. Honestly a language designed in this century with nil values is tragic compared to what exists in other languages.
- viraptor 5y ago
  > That an option type is 'safer' only helps enforce good habits. It enforces compilation result not habits. "to a programmer who understands what he or she is working with" - one day you'll learn that everyone makes mistakes regardless of experience, but it's better to accept and adjust to that fact before it bites you ;)

silisili 5y ago

I appreciate the thought out response, but do understand the concept. It just changes the onus somewhat. A well written Go program will check for and handle nil up front. That an option type is 'safer' only helps enforce good habits. I'm not against the idea, I just don't see the big benefit to a programmer who understands what he or she is working with. Unless the value is solely not having to think about nil cases, in which case I'd argue the value is very little.

andrewjf 5y ago
Relying on “well written” to prevent bugs is just a fantasy. Non-nullable types and compiler enforced checking of present/non-present values leads to more readable and more maintainable code. And there’s a mountain of CVEs, and bugs in go programs, to prove it. Maybe you just have to experience it. Honestly a language designed in this century with nil values is tragic compared to what exists in other languages.
viraptor 5y ago
> That an option type is 'safer' only helps enforce good habits. It enforces compilation result not habits. "to a programmer who understands what he or she is working with" - one day you'll learn that everyone makes mistakes regardless of experience, but it's better to accept and adjust to that fact before it bites you ;)