5 ms·

> This is something I had not discovered yet No doubt because the Go team disagrees. They have been abundantly clear that, from their point of view, goroutines

> This is something I had not discovered yet No doubt because the Go team disagrees. They have been abundantly clear that, from their point of view, goroutines should be used and even used as part of the public API when it makes sense. That said, it is still probably really good advice for newcomers who won't have a good understanding for the cases where it does make sense, and especially because goroutines are the shiny thing every newcomer wants to play with and will try to find uses that don't make sense just to use it. As a rule, you don't want to force the caller into things they might not want. In the vast majority of cases, a synchronous API is what you will want to give them as it is the most versatile. And, really, that's something that applies generally. For example, in the case of the common (T, error) pattern, you will want to ensure T is always useful even when there is an error. The caller may not care about the error condition. That's not you for, the library author, to decide. The fewer assumptions you can make about the caller the better.

tsimionescu 3y ago
> For example, in the case of the common (T, error) pattern, you will want to ensure T is always useful even when there is an error. The caller may not care about the error condition. This applies to maybe 0.1% of functions. The overwhelming majority of functions, in the Go stdlib as well as real projects, that return (T, error) return an empty meaningless value for the error cases.
- randomdata 3y ago
  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

tsimionescu 3y ago

> For example, in the case of the common (T, error) pattern, you will want to ensure T is always useful even when there is an error. The caller may not care about the error condition. This applies to maybe 0.1% of functions. The overwhelming majority of functions, in the Go stdlib as well as real projects, that return (T, error) return an empty meaningless value for the error cases.

randomdata 3y ago
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