5 ms·

> The way nil works is pretty simple. Unexpected cases are cases that didn't understand how nil works. I mean sure, but wouldn't it just be strictly better if

> The way nil works is pretty simple. Unexpected cases are cases that didn't understand how nil works. I mean sure, but wouldn't it just be strictly better if there was just not null values and you specifically had to handle the present vs non-present case (i.e. Haskell's "maybe" type or other sum type construct)? Any non-trivial codebase is going to have programming errors where "nil" crashes the program where the compiler could literally have told you that your code was incomplete. > Errors as values is how the language works, and how I prefer it. No magic, make sure each step works. When I hammer a nail, I can tell immediately if I miss it, and deal with it. I don't have a catchall that sees I wasn't wearing safety glasses and makes some random hammer error Not following the analogy, but seems to rely on writing perfect code the first time, which is not possible. Nor are any of the proposed improvements "magic". > Then again, I also don't think generics are a good thing, so maybe I'm just against change to the language at all. With respect, it definitely sounds like it. Which is fine, but there's serious design problems with go that can be improved over time, and it's not a personal affront.

silisili 5y ago
Nil values are especially useful for knowing the caller didn't set something. A zero value type cannot provide you such information.
- andrewjf 5y ago
  "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 ;)
- masklinn 5y ago
  The comment you’re replying to is not talking about “a zero value type”, it’s talking about option types aka separating nullability and value. If you don’t know about that, please educate yourself, or at least ask questions, instead of replying with nonsense. Same with “errors as values”, nobody is arguing about or against “errors as values” (then again I can’t say I know any language where that’s not the case, possibly VB? Exceptions certainly are errors and first-class values so they’re errors as values).
  - silisili 5y ago
    Thank you for your wisdom.

silisili 5y ago

Nil values are especially useful for knowing the caller didn't set something. A zero value type cannot provide you such information.

andrewjf 5y ago
"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 ;)
masklinn 5y ago
The comment you’re replying to is not talking about “a zero value type”, it’s talking about option types aka separating nullability and value. If you don’t know about that, please educate yourself, or at least ask questions, instead of replying with nonsense. Same with “errors as values”, nobody is arguing about or against “errors as values” (then again I can’t say I know any language where that’s not the case, possibly VB? Exceptions certainly are errors and first-class values so they’re errors as values).
- silisili 5y ago
  Thank you for your wisdom.