6 ms·

I recommend you read your own posts sometimes. Your claim of "in Go values must always be useful" was rebutted multiple times. That you're trying to move the go

by awused 3y ago

I recommend you read your own posts sometimes. Your claim of "in Go values must always be useful" was rebutted multiple times. That you're trying to move the goalposts to something neither of us was arguing speaks loudly. You also dance dishonestly around the actual point I made in that last post. Again, I'd recommend following your advice about reading a thread before responding to it.

randomdata 3y ago
> Your claim of "in Go values must always be useful" I said no such thing. I said idiomatic Go indicates that you must always make values useful. This is an onus placed on the programmer, not something guaranteed by the language. However, since the Either monad here was said to be introduced to wrap idiomatic Go code, not whatever haphazardly written Go code you happened to find in a SourceForge repository, that is of relevance. > was rebutted multiple times Cool. I must not have read it. There was a lot of weird shit in there that had nothing to do with anything. I'm not sure how that would even find relevance to the discussion taking place. I get that first year computer science programs are starting up and you're excited to share what you learned in your first week, but I really don't care. You are not going to tell me anything I haven't heard many times before.
- awused 3y ago
  >whatever haphazardly written Go code you happened to find Well, if the Go stdlib is haphazardly written and unidiomatic then I think the burden is on you to demonstrate that idiomatic Go, as per your definition, exists. >more baseless ad-hominem and ignoring the points I'll boil it down to one sentence: Go forces programmers to use (T, error) when it is not appropriate, and Go would be better if it did not.
  - randomdata 3y ago
    > Well, if the Go stdlib is haphazardly written and unidiomatic Yeah, the older parts of the standard library are definitely not idiomatic. Lots of functions in the stdlib which return errors don't even return an error type. But, of course they aren't idiomatic. Idiomatacy is emergent. They couldn't possibly have been written idiomatically. > I'll boil it down to one sentence: Go forces programmers to use (T, error) when it is not appropriate, and Go would be better if it did not. That may be true, but of no relevance. I can see why I didn't bother reading it. Thanks for clarifying that it would have been a waste of my time.
    - awused 3y ago
      So you've defined idiomatic Go code in your own way, that no one else's definitions match with, such that no idiomatic Go code actually exists. If no idiomatic Go code exists, then it's definitionally true that all idiomatic Go code is without flaws, but I don't agree with your personalized definition of idiomatic Go in the first place. >That may be true, but of no relevance. So you agree with this, and it rebuts the entire contents of the first post I responded to. I wonder why you were posting irrelevant, off-topic content yourself. But I'm glad you finally agree that Go isn't flawless.
      - Huggernaut 3y ago
        Just in support of your position, the Google Style Guide says the following: > If a function returns an error, callers must treat all non-error return values as unspecified unless explicitly documented otherwise It is absolutely not idiomatic to give any meaning to non-error values under error conditions in the usual case. That is extremely unusual and would be generally confusing. https://google.github.io/styleguide/go/decisions#returning-errors https://google.github.io/styleguide/go/decisions#returning-e...
        randomdata 3y ago
        > It is absolutely not idiomatic to give any meaning to non-error values under error conditions in the usual case. Based on what? We have come to see that it is beneficial to make zero values useful. In fact, Go Proverbs even says so. Likewise, we have learned it is useful to return the zero value when you have an error. Most commonly, this means returning nil, which is packed full of all kinds of useful information. Therefore, the T value can be expected to useful if the code is idiomatic. I'd love to see some real-world code you think is idiomatic, but doesn't return a useful T value when there is an error. > If a function returns an error, callers must treat all non-error return values as unspecified unless explicitly documented otherwise This is not at odds with that. This merely warns that not all code you may call will be idiomatic. In fact, if I recall correctly, doesn't os.Open (maybe os.Create) return an invalid file handle in some error cases? The standard library is old and what helped us eventually see what is idiomatic. It is decidedly not idiomatic for the most part. If you rely on a function being written idiomatically, then you are going to run into trouble, as that is not a guarantee (unless the documentation provides such a guarantee). But in the case of this Either wrapper, it explicitly states it is for use with idiomatic code, not any old code you can throw at it.

by awused 3y ago

randomdata 3y ago

> Your claim of "in Go values must always be useful" I said no such thing. I said idiomatic Go indicates that you must always make values useful. This is an onus placed on the programmer, not something guaranteed by the language. However, since the Either monad here was said to be introduced to wrap idiomatic Go code, not whatever haphazardly written Go code you happened to find in a SourceForge repository, that is of relevance. > was rebutted multiple times Cool. I must not have read it. There was a lot of weird shit in there that had nothing to do with anything. I'm not sure how that would even find relevance to the discussion taking place. I get that first year computer science programs are starting up and you're excited to share what you learned in your first week, but I really don't care. You are not going to tell me anything I haven't heard many times before.

awused 3y ago
>whatever haphazardly written Go code you happened to find Well, if the Go stdlib is haphazardly written and unidiomatic then I think the burden is on you to demonstrate that idiomatic Go, as per your definition, exists. >more baseless ad-hominem and ignoring the points I'll boil it down to one sentence: Go forces programmers to use (T, error) when it is not appropriate, and Go would be better if it did not.
- randomdata 3y ago
  > Well, if the Go stdlib is haphazardly written and unidiomatic Yeah, the older parts of the standard library are definitely not idiomatic. Lots of functions in the stdlib which return errors don't even return an error type. But, of course they aren't idiomatic. Idiomatacy is emergent. They couldn't possibly have been written idiomatically. > I'll boil it down to one sentence: Go forces programmers to use (T, error) when it is not appropriate, and Go would be better if it did not. That may be true, but of no relevance. I can see why I didn't bother reading it. Thanks for clarifying that it would have been a waste of my time.
  - awused 3y ago
    So you've defined idiomatic Go code in your own way, that no one else's definitions match with, such that no idiomatic Go code actually exists. If no idiomatic Go code exists, then it's definitionally true that all idiomatic Go code is without flaws, but I don't agree with your personalized definition of idiomatic Go in the first place. >That may be true, but of no relevance. So you agree with this, and it rebuts the entire contents of the first post I responded to. I wonder why you were posting irrelevant, off-topic content yourself. But I'm glad you finally agree that Go isn't flawless.
    - Huggernaut 3y ago
      Just in support of your position, the Google Style Guide says the following: > If a function returns an error, callers must treat all non-error return values as unspecified unless explicitly documented otherwise It is absolutely not idiomatic to give any meaning to non-error values under error conditions in the usual case. That is extremely unusual and would be generally confusing. https://google.github.io/styleguide/go/decisions#returning-errors https://google.github.io/styleguide/go/decisions#returning-e...
      - randomdata 3y ago
        > It is absolutely not idiomatic to give any meaning to non-error values under error conditions in the usual case. Based on what? We have come to see that it is beneficial to make zero values useful. In fact, Go Proverbs even says so. Likewise, we have learned it is useful to return the zero value when you have an error. Most commonly, this means returning nil, which is packed full of all kinds of useful information. Therefore, the T value can be expected to useful if the code is idiomatic. I'd love to see some real-world code you think is idiomatic, but doesn't return a useful T value when there is an error. > If a function returns an error, callers must treat all non-error return values as unspecified unless explicitly documented otherwise This is not at odds with that. This merely warns that not all code you may call will be idiomatic. In fact, if I recall correctly, doesn't os.Open (maybe os.Create) return an invalid file handle in some error cases? The standard library is old and what helped us eventually see what is idiomatic. It is decidedly not idiomatic for the most part. If you rely on a function being written idiomatically, then you are going to run into trouble, as that is not a guarantee (unless the documentation provides such a guarantee). But in the case of this Either wrapper, it explicitly states it is for use with idiomatic code, not any old code you can throw at it.