5 ms·

Not my experience. Some very early code did not recognize this, but since then pretty much everyone has come to agree that values should always be useful. If yo

Not my experience. Some very early code did not recognize this, but since then pretty much everyone has come to agree that values should always be useful. If you are writing a function today, there is no reason to not observe this. In practice, that typically means returning the zero value. To which idioms suggest that zero values should be useful. Rob Pike's Go Proverb[1] even states: "Make the zero value useful." Most commonly when returning (T, error) that zero value is nil. In Go, nil is a useful value! If the caller wants to observe the error state, great. But it is needlessly limiting if you force it upon them. That is not for the library author to decide. [1] https://go-proverbs.github.io https://go-proverbs.github.io

thowdfasdf23411 3y ago
Practically speaking, the (T, error) pattern is pervasive because there isn't any other alternative. Go simply lacks sum types. > Not my experience. To what experience do you speak of? My 5,000+ hours in kubernetes and terraform space tells me Rob Pike's views are fan fiction at best.
- randomdata 3y ago
  Let's be real, Kubernetes is a Java project with code that just happens to share some resemblance to Go syntax. It's also one of the oldest projects using Go, long predating the "make zero values useful" proverb, so it is not surprising that it doesn't follow the idioms recognized today. Idioms cannot be conceived in advance. They emerge from actual use after finding out what works and what doesn't. What new code being written today is violating that pattern?
  - eweise 3y ago
    I usually return zero values just because its easy, not because its useful. I don't expect the caller to use the return value if err !=nil and haven't heard anything to the contrary on my team. If Go were a more powerful language, we would be returning Either[A,B] not multiple return values, which would guarantee that you rely on one or the other, not some weird in-between case.
    - randomdata 3y ago
      > I don't expect the caller to use the return value if err !=nil and haven't heard anything to the contrary on my team. Yet you admit to following the advice for error, returning the zero value for err and making it useful when you do. If you don't have a meaningful error state, why not just return junk? Clearly you recognize the value of making the return values useful, always. Why make exceptions?
      - eweise 3y ago
        if I need to return some person,error how do I return junk for the person? I just return person{}, error. I guess I could fill person out with a bunch of silly values but why would I do that work? If there was some easier way to make a person and it was filled with junk, I wouldn't hesitate to use it because the caller would never use the value.
        randomdata 3y ago
        Logically, in that case you would return nil, just like you do for error. There is no person to return. nil is how Go signifies the absence of something. nil is useful, as proven by error. Why make exceptions? It’s funny how people forget how to write software as soon as the word error shows up. I don’t get it.
        ongy 3y ago
        Because nil panics on member accessors... It's the opposite of what you claim to be the standard in go. Thanks for demonstrating that you forget how to write software around erros.
        randomdata 3y ago
        What are you returning for error in its “junk” state, then? Clearly not nil, else by your assertion your code will panic. error has member accessors you will call - Error() if nothing else. Methinks you’ve not thought this through. What’s it about the word error that trips up programmers like this?
  - thowdfasdf23411 3y ago
    > What new code being written today is violating that pattern? You are putting the burden of proof on me now? How unfair, You didn't bring any. Go to CNCF and pick anything written in Go. > Let's be real, Kubernetes is a Java project Let's be real, Rob Pike is the flat earther of PLT. Sum types are Rob Pike's Foucault pendulum.
    - randomdata 3y ago
      > You are putting the burden of proof on me now? No. I don't give a shit about what you do. Where did you dream up this idea? > Let's be real, Rob Pike is the flat earther of PLT. No doubt, but when using the programming language of flat earthers, one has to accept that the particular world is, indeed, flat. But the advice is undeniably sound. There is no programming language where you should leave someone hanging with junk values. You might avoid junk in other languages using some other means (e.g. sum types), but it is to be avoided all the same.
tsimionescu 3y ago
Zero and nil values are almost always bogus. The Go language itself doesn't even respect that proverb: the zero value of a map is not a useful map. There are some rare cases where a 0 value is actually meaningful in some way. But even for types where it is fully functional like integers, it's often not meaningful in the specific context it is used.
deergomoo 3y ago
One problem I've found as a newcomer to Go (and I'm perfectly willing to accept that I just haven't developed the right "language mindset" yet) is that the zero value can be problematic—particularly for scalar types—because it's often a perfectly valid value in a model where you need a way to indicate an invalid value. Obviously if there is a possibility of invalidity, you would expect the caller to check the error, but the fact that I always have to return something as the callee, and always have to make sure I'm not accidentally using the value in error conditions as the caller, is just asking for mistakes to me. I appreciate that it's not the path Go has chosen to tread, but I find Result<T, Error> to be so much more of a foolproof pattern than (T, error), especially considering prevention-of-foot-shooting is an established Go design goal. (Equally obviously you could use a pointer and return nil, but I find that muddles the semantics, because there are multiple reasons you might opt to use pointers besides the ability to express "no value".)
- Kamq 3y ago
  If the zero value is valid, I usually just use a pointer to the scalar type in question
- randomdata 3y ago
  Given (T, error), what do you return for error when no error occurred? When error is "invalid"? The caller is, no doubt, expecting you to be consistent, so the answer for T no doubt lies therein. There is nothing special about errors.
Joker_vD 3y ago
I've seen just two APIs that returned non-nil/non-default T (representing the partially completed work) with a non-nil error, and those were a constant source of bugs and errors. I've changed those to always return dummy empty T, and even though the retries now hurt performance more (they could not re-use partial completed result), it was a much more straight-forward code.

thowdfasdf23411 3y ago

Practically speaking, the (T, error) pattern is pervasive because there isn't any other alternative. Go simply lacks sum types. > Not my experience. To what experience do you speak of? My 5,000+ hours in kubernetes and terraform space tells me Rob Pike's views are fan fiction at best.

randomdata 3y ago
Let's be real, Kubernetes is a Java project with code that just happens to share some resemblance to Go syntax. It's also one of the oldest projects using Go, long predating the "make zero values useful" proverb, so it is not surprising that it doesn't follow the idioms recognized today. Idioms cannot be conceived in advance. They emerge from actual use after finding out what works and what doesn't. What new code being written today is violating that pattern?
- eweise 3y ago
  I usually return zero values just because its easy, not because its useful. I don't expect the caller to use the return value if err !=nil and haven't heard anything to the contrary on my team. If Go were a more powerful language, we would be returning Either[A,B] not multiple return values, which would guarantee that you rely on one or the other, not some weird in-between case.
  - randomdata 3y ago
    > I don't expect the caller to use the return value if err !=nil and haven't heard anything to the contrary on my team. Yet you admit to following the advice for error, returning the zero value for err and making it useful when you do. If you don't have a meaningful error state, why not just return junk? Clearly you recognize the value of making the return values useful, always. Why make exceptions?
    - eweise 3y ago
      if I need to return some person,error how do I return junk for the person? I just return person{}, error. I guess I could fill person out with a bunch of silly values but why would I do that work? If there was some easier way to make a person and it was filled with junk, I wouldn't hesitate to use it because the caller would never use the value.
      - randomdata 3y ago
        Logically, in that case you would return nil, just like you do for error. There is no person to return. nil is how Go signifies the absence of something. nil is useful, as proven by error. Why make exceptions? It’s funny how people forget how to write software as soon as the word error shows up. I don’t get it.
        ongy 3y ago
        Because nil panics on member accessors... It's the opposite of what you claim to be the standard in go. Thanks for demonstrating that you forget how to write software around erros.
        randomdata 3y ago
        What are you returning for error in its “junk” state, then? Clearly not nil, else by your assertion your code will panic. error has member accessors you will call - Error() if nothing else. Methinks you’ve not thought this through. What’s it about the word error that trips up programmers like this?
- thowdfasdf23411 3y ago
  > What new code being written today is violating that pattern? You are putting the burden of proof on me now? How unfair, You didn't bring any. Go to CNCF and pick anything written in Go. > Let's be real, Kubernetes is a Java project Let's be real, Rob Pike is the flat earther of PLT. Sum types are Rob Pike's Foucault pendulum.
  - randomdata 3y ago
    > You are putting the burden of proof on me now? No. I don't give a shit about what you do. Where did you dream up this idea? > Let's be real, Rob Pike is the flat earther of PLT. No doubt, but when using the programming language of flat earthers, one has to accept that the particular world is, indeed, flat. But the advice is undeniably sound. There is no programming language where you should leave someone hanging with junk values. You might avoid junk in other languages using some other means (e.g. sum types), but it is to be avoided all the same.

tsimionescu 3y ago

Zero and nil values are almost always bogus. The Go language itself doesn't even respect that proverb: the zero value of a map is not a useful map. There are some rare cases where a 0 value is actually meaningful in some way. But even for types where it is fully functional like integers, it's often not meaningful in the specific context it is used.

deergomoo 3y ago

One problem I've found as a newcomer to Go (and I'm perfectly willing to accept that I just haven't developed the right "language mindset" yet) is that the zero value can be problematic—particularly for scalar types—because it's often a perfectly valid value in a model where you need a way to indicate an invalid value. Obviously if there is a possibility of invalidity, you would expect the caller to check the error, but the fact that I always have to return something as the callee, and always have to make sure I'm not accidentally using the value in error conditions as the caller, is just asking for mistakes to me. I appreciate that it's not the path Go has chosen to tread, but I find Result<T, Error> to be so much more of a foolproof pattern than (T, error), especially considering prevention-of-foot-shooting is an established Go design goal. (Equally obviously you could use a pointer and return nil, but I find that muddles the semantics, because there are multiple reasons you might opt to use pointers besides the ability to express "no value".)

Kamq 3y ago
If the zero value is valid, I usually just use a pointer to the scalar type in question
randomdata 3y ago
Given (T, error), what do you return for error when no error occurred? When error is "invalid"? The caller is, no doubt, expecting you to be consistent, so the answer for T no doubt lies therein. There is nothing special about errors.

Joker_vD 3y ago

I've seen just two APIs that returned non-nil/non-default T (representing the partially completed work) with a non-nil error, and those were a constant source of bugs and errors. I've changed those to always return dummy empty T, and even though the retries now hurt performance more (they could not re-use partial completed result), it was a much more straight-forward code.