4 ms·

I have never seen a language successfully eliminate nil/null and zero values after the fact. Once they're in, they're there to stay.

• throwaway894345 5y ago
  Yeah, I have no illusions that Go will walk that back, especially considering its compatibility promise. It's a thorn in the side, but people also exaggerate it dramatically while overlooking major issues in other languages.
• dgb23 5y ago
  You can have robust and ergonomic code around nils if they are part of your type signatures and/or get some good language and standard library support: In Clojure (Lisp) a nil is treated as a value which flows nicely through code, there are many idioms and utilities that are built for this and compose well. In Kotlin, Typescript, PHP there are unions which I find much more ergonomic than sum types for this use-case.
  • throwaway894345 5y ago
    > You can have robust and ergonomic code around nils if they are part of your type signatures Go has `nil` built into the type signature, but the problem is that all reference types are inherently nil-able, and value types can't be nil (although they can have their own in-band zero values). This means you either pass around values (with the entailed overhead and copy semantics) or you pass around nil-able references. Why would unions be more ergonomic than sum types? Presumably they would have the same ergonomics?
    • dgb23 5y ago
      > Why would unions be more ergonomic than sum types? Presumably they would have the same ergonomics? For this use case (can be a some type OR nil) they are more ergonomic because it is an actual OR, not a separate container. You want the thing as-is and handle the case where it isn't there not go through an intermediary type.
      • throwaway894345 5y ago
        I'm not sure I'm following. Rust allows: println!("{}", if x == None { "foo" } else { "bar" }); How would unions make this more ergonomic? For example, in Python (with type annotations), you would have to do: print("foo" if x == None else "bar")