3 ms·

This is one of the warts I wish Go would fix (implementing Rust-like enums, and ideally getting rid of zero values and nils, but these things won’t happen). Eve

This is one of the warts I wish Go would fix (implementing Rust-like enums, and ideally getting rid of zero values and nils, but these things won’t happen). Even still, Go is the most productive language I’ve used because it turns out type-systems (cool though they are) are overrated—you only need enough of a type system to keep things documented for humans and tools. 95% type safety seems to be the sweet spot (peak productivity) after which productivity begins to rapidly diminish. It’s more important to have decent performance, good tooling (simple with sane defaults), small learning curve, great deployment story, etc.

ttfkam 5y ago
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")

ttfkam 5y ago

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")