4 ms·
> Once you know what's going on, it totally makes sense Anything “makes sense” from an operational point of view, so long as you internalize the rules. But doe
by catnaroek 9y ago
> Once you know what's going on, it totally makes sense
Anything “makes sense” from an operational point of view, so long as you internalize the rules. But does Go's handling of `nil` denote anything you ever actually want to express, regardless of language?
> it violates natural-looking assumptions about algebraic equality
No, Go's handling of `nil` doesn't violate anything about equality: everything (besides floats, but you can't fault Go for those) is equal to itself and to nothing else. But the syntax (i.e. using a single unadorned token `nil`) does a very poor job of reflecting the language's semantics (the existence fo multiple `nil` values, all different from one another).
- dilap 9y agoI'm sure there are uses for it; in this case, since making nil pointers not work would require extra rules, it doesn't seem worth doing. A suggestion I saw on reddit was to use a different word for "nil" for interfaces ("unset" or something), which would make the gotchya have less bite. And I wasn't trying to say nil-to-interface violated anything real, just that it violated natural-to-make-but-actually-untrue assumptions (which is I guess pretty much the definition of a gotchya): If we have a = nil b = a it's natural (but incorrect) to assume that we have b == nil Basically, I agree with you that the syntax is being poorly suggestive of the semantics. I like the "unset" suggestion because then we'd have: a = nil b = a which wouldn't falsely suggest b == unset Too late now, though.