3 ms·

I've been using Go for almost a decade, and I don't recall this ever biting me. It doesn't feel like a trap. Go has a convention of documenting each function w

I've been using Go for almost a decade, and I don't recall this ever biting me. It doesn't feel like a trap. Go has a convention of documenting each function with a comment (which is adhered to by the standard library, my own code, and any other code I'd consider worthy of depending on). So when I think this subtlety matters, I check the documentation. Usually I don't care either way: When I get a non-nil error, I typically don't care about the other result (whether partial or the zero value). The distinction rarely matters in practice (and when it does, the documentation is there). I think this simplicity is the right tradeoff (vs. being burdened with more types to think about).

lmm 3y ago
How is a type more of a burden than documentation? You're saying that consistent documentation is a good thing, but types enforce more consistency and integrate better with tools.
- beautron 3y ago
  Documentation has immense value beyond just this specific error situation. Its a burden worth taking on regardless of how errors are handled. So it's not that a type is more of a burden than documentation, but rather that a type is an additional burden (since we're taking on the documentation burden either way). I like that Go's error handling is simple enough that I can keep all its rules in my head. And I like that the other parts of Go are simple like that too. It allows me to easily know exactly what is going on at the language level (while my attention is focused on higher levels).
  - lmm 3y ago
    The more you can shift into types the less you need to put in ad-hoc documentation, so it's not an extra burden. Conversely, if you "keep the language level rules simple" by shifting more stuff from the types into the documentation, that's not making it easier to think about IME - the more you can shift into the lower levels the better, so the documentation can focus on the higher-level things you weren't able to encode in the types.
et1337 3y ago
I’ve been bitten by it in production. Whenever I see this partial result pattern, it’s always a function that USUALLY returns nil plus an error. In one special case, it returns a partial result plus an error. This is a nil pointer panic waiting to happen.
- beautron 3y ago
  The caller can check if the result != nil. If I get a result that came with a non-nil error, and I still plan to do something with the result, then it seems natural to think about the possibility that the result might be nil. I would consult the function's documentation, and maybe its source, and then maybe put in a nil check. This is too rare a problem to be worth adding complexity to the language. There needs to be a big payoff for adding complexity. A language gets hard to use if it adds micro-complexities all over the place for the sake of preventing rare programming mistakes.

lmm 3y ago

How is a type more of a burden than documentation? You're saying that consistent documentation is a good thing, but types enforce more consistency and integrate better with tools.

beautron 3y ago
Documentation has immense value beyond just this specific error situation. Its a burden worth taking on regardless of how errors are handled. So it's not that a type is more of a burden than documentation, but rather that a type is an additional burden (since we're taking on the documentation burden either way). I like that Go's error handling is simple enough that I can keep all its rules in my head. And I like that the other parts of Go are simple like that too. It allows me to easily know exactly what is going on at the language level (while my attention is focused on higher levels).
- lmm 3y ago
  The more you can shift into types the less you need to put in ad-hoc documentation, so it's not an extra burden. Conversely, if you "keep the language level rules simple" by shifting more stuff from the types into the documentation, that's not making it easier to think about IME - the more you can shift into the lower levels the better, so the documentation can focus on the higher-level things you weren't able to encode in the types.

et1337 3y ago

I’ve been bitten by it in production. Whenever I see this partial result pattern, it’s always a function that USUALLY returns nil plus an error. In one special case, it returns a partial result plus an error. This is a nil pointer panic waiting to happen.

beautron 3y ago
The caller can check if the result != nil. If I get a result that came with a non-nil error, and I still plan to do something with the result, then it seems natural to think about the possibility that the result might be nil. I would consult the function's documentation, and maybe its source, and then maybe put in a nil check. This is too rare a problem to be worth adding complexity to the language. There needs to be a big payoff for adding complexity. A language gets hard to use if it adds micro-complexities all over the place for the sake of preventing rare programming mistakes.