6 ms·

> In Go, you are always forced by the language to return a value of type "A or B, including both or neither." The consumer isn't any more in control, it just ha

> In Go, you are always forced by the language to return a value of type "A or B, including both or neither." The consumer isn't any more in control, it just has to guess whether "both or neither" are possible return types. it does not have to guess convention dictates either one or the other is convention enough? is it roughly the same as compiler-enforced rules? you're free to say "no" but it is not like a guarantee

awused 3y ago
>convention dictates either one or the other Convention is just an educated guess. >is it [convention] roughly the same as compiler-enforced rules? No. The answer is no. I'm not only free to say "no," but if I'm honest and truthful I am compelled to say "no."
- preseinger 3y ago
  > Convention is just an educated guess. at some absolute level yes, but at any pragmatic level no, definitely not > No. The answer is no. I'm not only free to say "no," but if I'm honest and truthful I am compelled to say "no." nope! wrong. do not pass go, etc. -- it's a spectrum
  - awused 3y ago
    >nope! wrong. do not pass go, etc. -- it's a spectrum You are simply incorrect, there's no nuance or room for interpretation. A compiler can guarantee "A or B, but not both or neither", "A or B or both, but never neither", or even "A or B or both or neither" but convention for (A, B) in Go cannot, therefore it is not as good. Go's conventions are not as good as a decent type system, there's no spectrum about it; Go is always "A or B or both or neither" with no ability to exclude impossible/nonsense cases. In Go if I want to write robust, correct code I must always handle all 2^N cases for N arguments, which no one actually does.
    - preseinger 3y ago
      you're saying that guarantees which are not enforced by the compiler are "not as good" as those which are this is not correct but i'm not sure how to convince you of this truth, so (shrug)
      - awused 3y ago
        Well, yes. I do think something that is guaranteed is better than something that is not guaranteed. You've at least somewhat accurately captured my position, though with the weird implicit assumption that "guaranteed by convention" means anything at all. >but i'm not sure how to convince you of this truth, so (shrug) You'd need some pretty compelling evidence to convince me that something that is not guaranteed is as good as something that is guaranteed, so I can see why you're struggling. With your admissions, all I can really say is good luck convincing me or anyone.
simiones 3y ago
This whole thread was started by someone arguing that Go is superior because they're claiming Go's convention is "both", i.e. they claim you can generally safely do things like `if file, _ := getFile(); file != nil {....}`. So at the very least it seems that there is no very strong convention.
- preseinger 3y ago
  that person was wrong
  - simiones 3y ago
    Yes, demonstrating the problem with relying on conventions instead of compiler-enforceable patterns.
    - preseinger 3y ago
      not really do you not do code review?

awused 3y ago

>convention dictates either one or the other Convention is just an educated guess. >is it [convention] roughly the same as compiler-enforced rules? No. The answer is no. I'm not only free to say "no," but if I'm honest and truthful I am compelled to say "no."

preseinger 3y ago
> Convention is just an educated guess. at some absolute level yes, but at any pragmatic level no, definitely not > No. The answer is no. I'm not only free to say "no," but if I'm honest and truthful I am compelled to say "no." nope! wrong. do not pass go, etc. -- it's a spectrum
- awused 3y ago
  >nope! wrong. do not pass go, etc. -- it's a spectrum You are simply incorrect, there's no nuance or room for interpretation. A compiler can guarantee "A or B, but not both or neither", "A or B or both, but never neither", or even "A or B or both or neither" but convention for (A, B) in Go cannot, therefore it is not as good. Go's conventions are not as good as a decent type system, there's no spectrum about it; Go is always "A or B or both or neither" with no ability to exclude impossible/nonsense cases. In Go if I want to write robust, correct code I must always handle all 2^N cases for N arguments, which no one actually does.
  - preseinger 3y ago
    you're saying that guarantees which are not enforced by the compiler are "not as good" as those which are this is not correct but i'm not sure how to convince you of this truth, so (shrug)
    - awused 3y ago
      Well, yes. I do think something that is guaranteed is better than something that is not guaranteed. You've at least somewhat accurately captured my position, though with the weird implicit assumption that "guaranteed by convention" means anything at all. >but i'm not sure how to convince you of this truth, so (shrug) You'd need some pretty compelling evidence to convince me that something that is not guaranteed is as good as something that is guaranteed, so I can see why you're struggling. With your admissions, all I can really say is good luck convincing me or anyone.

simiones 3y ago

This whole thread was started by someone arguing that Go is superior because they're claiming Go's convention is "both", i.e. they claim you can generally safely do things like `if file, _ := getFile(); file != nil {....}`. So at the very least it seems that there is no very strong convention.

preseinger 3y ago
that person was wrong
- simiones 3y ago
  Yes, demonstrating the problem with relying on conventions instead of compiler-enforceable patterns.
  - preseinger 3y ago
    not really do you not do code review?