3 ms·

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, l

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?
      - ongy 3y ago
        On top of the issue with nil not being a useful value for most types Nil requires pointer values. I.e. it's impossible to know whether something is a pointer to allow for nil, or because a copy would be prohibitively expensive and therefore references are used, or even because it's into a mutable structure. Go's overlapping of implicit nullability and by value/by reference marker make it entirely useless to build information into APIs / necessarily promotes the value into a different type to use.
      - eweise 3y ago
        That's not what my team of gofers decided. Apparently zero is better than nil. I know how to write code but Go is its own thing. I mean the idea of returning multiple values is totally goofy in itself.
        3y ago
  - ongy 3y ago
    No. And GP explictly said they don't tend to make it useful, but only do it when it's easy. Making the return value of e.g. a database handle always "useful" is a ridiculously dangerous idea that can lead to application bugs further down the route becaause some list/get returned an empty value to continue the pattern of "useful" empty values. The main reason there is ever a useful error next to a non-nill err is because go doesn't have a useful way to not do it.
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.

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?
    - ongy 3y ago
      On top of the issue with nil not being a useful value for most types Nil requires pointer values. I.e. it's impossible to know whether something is a pointer to allow for nil, or because a copy would be prohibitively expensive and therefore references are used, or even because it's into a mutable structure. Go's overlapping of implicit nullability and by value/by reference marker make it entirely useless to build information into APIs / necessarily promotes the value into a different type to use.
    - eweise 3y ago
      That's not what my team of gofers decided. Apparently zero is better than nil. I know how to write code but Go is its own thing. I mean the idea of returning multiple values is totally goofy in itself.
      - 3y ago
- ongy 3y ago
  No. And GP explictly said they don't tend to make it useful, but only do it when it's easy. Making the return value of e.g. a database handle always "useful" is a ridiculously dangerous idea that can lead to application bugs further down the route becaause some list/get returned an empty value to continue the pattern of "useful" empty values. The main reason there is ever a useful error next to a non-nill err is because go doesn't have a useful way to not do it.

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.