4 ms·

One problem with Go is that is uses multiple return values to indicate errors instead of alternative return values. When you call strconv.ParseFloat, you alway

One problem with Go is that is uses multiple return values to indicate errors instead of alternative return values. When you call strconv.ParseFloat, you always get back two values, the error code and... wait, what float do you get back when there's an error? If you're going to use return values to indicate errors (and certainly I feel that there are reasons to use them, exceptions vs error codes is not an either/or proposition IMO), you should use sum types and return either an error or the correct value and have a mechanism to make sure you handle both cases. ML and Haskell get this right, it's a shame Go overlooked them in this regard.

_ak 14y ago
> One problem with Go is that is uses multiple return values to indicate errors instead of alternative return values. When you call strconv.ParseFloat, you always get back two values, the error code and... wait, what float do you get back when there's an error? Why would you even be interested in the float when there's an error?
- masklinn 14y ago
  That's his point: why do you get something typed as float back when there's an error? And what does that thing mean?
  - _ak 14y ago
    But if there was an error, WHY WOULD YOU EVEN BOTHER?! Read the documentation what it says about the value in case of an error, and stop inflating a non-issue.
    - papsosouid 14y ago
      Human beings are capable of making mistakes, that's the entire point. If you forgot to check the error code in go, then you will end up using that non-float float that shouldn't exist as if it were really a float. In a decent language, you get either an error or a float, you have no way to accidently use the float if an error occurred.
      - _ak 14y ago
        > If you forgot to check the error code in go, then you will end up using that non-float float that shouldn't exist as if it were really a float. Consider the following code: foo, err := strconv.ParseFloat(...) If you don't handle the error (e.g. by forgetting), the compiler will show an error because you declared err, but didn't use it. If you write foo, _ := strconv.ParseFloat(...) instead, you deliberately choose to ignore the error. > In a decent language, you get either an error or a float, you have no way to accidently use the float if an error occurred. Making these specifics a criteria for decency is nothing but arrogance.
        papsosouid 14y ago
        >If you don't handle the error (e.g. by forgetting), the compiler will show an error because you declared err, but didn't use it. But if I make a mistake like I mentioned previously, I could very well use err, thus not getting a compiler warning, and still also use foo, which is a whoknowswhat. It should be an Either, not two seperate return values. >Making these specifics a criteria for decency is nothing but arrogance. Having opinions is not arrogance. You should consider that when someone shares their opinion, they are not declaring that everyone everywhere must acknowledge it as a universal truth.
        Evbn 14y ago
        And in Haskell you could make the mistake of ignoring the error and writing Right x = leftOrRight y And get a runtime crash when a Left shows up, Or Just x = justOrNone y And crash on None.
        gnuvince 14y ago
        As you point out, in both cases the program will crash, which for many people is preferable to the program churning along with invalid data. In Go with multiple return values, it is possible to have a code path where there's an error but still use what would've been the result of the procedure. In ML or Haskell when using sum types, that code path does not exist.

_ak 14y ago

> One problem with Go is that is uses multiple return values to indicate errors instead of alternative return values. When you call strconv.ParseFloat, you always get back two values, the error code and... wait, what float do you get back when there's an error? Why would you even be interested in the float when there's an error?

masklinn 14y ago
That's his point: why do you get something typed as float back when there's an error? And what does that thing mean?
- _ak 14y ago
  But if there was an error, WHY WOULD YOU EVEN BOTHER?! Read the documentation what it says about the value in case of an error, and stop inflating a non-issue.
  - papsosouid 14y ago
    Human beings are capable of making mistakes, that's the entire point. If you forgot to check the error code in go, then you will end up using that non-float float that shouldn't exist as if it were really a float. In a decent language, you get either an error or a float, you have no way to accidently use the float if an error occurred.
    - _ak 14y ago
      > If you forgot to check the error code in go, then you will end up using that non-float float that shouldn't exist as if it were really a float. Consider the following code: foo, err := strconv.ParseFloat(...) If you don't handle the error (e.g. by forgetting), the compiler will show an error because you declared err, but didn't use it. If you write foo, _ := strconv.ParseFloat(...) instead, you deliberately choose to ignore the error. > In a decent language, you get either an error or a float, you have no way to accidently use the float if an error occurred. Making these specifics a criteria for decency is nothing but arrogance.
      - papsosouid 14y ago
        >If you don't handle the error (e.g. by forgetting), the compiler will show an error because you declared err, but didn't use it. But if I make a mistake like I mentioned previously, I could very well use err, thus not getting a compiler warning, and still also use foo, which is a whoknowswhat. It should be an Either, not two seperate return values. >Making these specifics a criteria for decency is nothing but arrogance. Having opinions is not arrogance. You should consider that when someone shares their opinion, they are not declaring that everyone everywhere must acknowledge it as a universal truth.
        Evbn 14y ago
        And in Haskell you could make the mistake of ignoring the error and writing Right x = leftOrRight y And get a runtime crash when a Left shows up, Or Just x = justOrNone y And crash on None.
        gnuvince 14y ago
        As you point out, in both cases the program will crash, which for many people is preferable to the program churning along with invalid data. In Go with multiple return values, it is possible to have a code path where there's an error but still use what would've been the result of the procedure. In ML or Haskell when using sum types, that code path does not exist.