3 ms·

> They could've at least looked at what other languages were doing at the time Other languages at the time were doing the exact same thing, except, maybe, wrap

by 9rx 2y ago

> They could've at least looked at what other languages were doing at the time Other languages at the time were doing the exact same thing, except, maybe, wrapping the error in a monad such that you have to check the error before doing anything with value, but still with "if" or an if-like construct. But that is unnecessary in Go as it believes that values should always be useful – which means you don't need to even consider the error to use the value.

int_19h 2y ago
> you don't need to even consider the error to use the value That's how you get garbage (but valid) values fed as input to your code, eventually resulting in garbage output produced on the other end of the pipe. Always fun to debug.
- 9rx 2y ago
  > That's how you get garbage (but valid) values fed as input to your code If you face a function author who doesn't know what the hell they are doing and, as a result, foolishly feeds you garbage, then yes, it is possible for that garbage to propagate unknowingly. But when faced with a function author that doesn't know what the hell they are doing, that's going to be a problem no matter what. No language construct ever conceived can save you from someone who doesn't know what the hell they are doing. They will do foolish things in every language ever created. -- That is not a reasonable position. If a function is written sensibly, the value can never be garbage. How could it be?
  - maleldil 2y ago
    What does this even mean? If I read from a file that doesn't exist, what should the returned object be? Isn't the state of the file directly tied to the error? If I ignore the error and try to use the file anyway, the following operations wouldn't make sense. How can you read from a non-existent file?
    - 9rx 2y ago
      > If I read from a file that doesn't exist, what should the returned object be? First things first, how can you read from a file that doesn't exist? Even you questioned that later, so this is a strange question. – Do you mean if you try to open a file that doesn't exist? nil would be a reasonable value. It is how Go signifies the absence of something. nil is always useful and with `if file == nil` will tell you that the file isn't there. No need to observe the error. If you need to know why the file isn't there then, sure, you're also going to have to look at the error. Sometimes that is important. In the case of opening a file you realistically will need to know why it failed to open so that you can resolve the condition, but in other cases you don't need to worry about why it failed. Checking the error would be unnecessary in those cases, assuming the function author has some understanding of how to make even half-decent APIs. Let's assume here, for the sake of discussion, that you have no need to know why the file was unable to opened. Again, how do you envision garbage propagating into the rest of your program?
      - int_19h 2y ago
        Let's say you successfully opened a file, but it was on removable media which got ejected mid-read.
        deleted 2y ago
        [deleted]
        9rx 2y ago
        You’d return -1. A successful read won’t read negative bytes. The non-error value remains useful.
        int_19h 2y ago
        That's actually a great example. Note that it is a distinct sentinel error value that needs to be checked for (contrary to your initial assertion), and if you forget to do it, you'll just end up with garbage. But also, let's say the read function in question is named ReadInt32. Then what does it return on error?
tubthumper8 2y ago
> But that is unnecessary in Go as it believes that values should always be useful – which means you don't need to even consider the error to use the value. Is this true? Are values always useful? You shouldn't even need to consider the error? For example, if GPS errored while calling an Uber, is it useful to ignore the error and instead display the Uber driver as being in the middle of the ocean? https://www.reddit.com/r/uberdrivers/comments/zjpv69/well_how_could_i_pass_up_this_ride/ https://www.reddit.com/r/uberdrivers/comments/zjpv69/well_ho...

by 9rx 2y ago

int_19h 2y ago

> you don't need to even consider the error to use the value That's how you get garbage (but valid) values fed as input to your code, eventually resulting in garbage output produced on the other end of the pipe. Always fun to debug.

9rx 2y ago
> That's how you get garbage (but valid) values fed as input to your code If you face a function author who doesn't know what the hell they are doing and, as a result, foolishly feeds you garbage, then yes, it is possible for that garbage to propagate unknowingly. But when faced with a function author that doesn't know what the hell they are doing, that's going to be a problem no matter what. No language construct ever conceived can save you from someone who doesn't know what the hell they are doing. They will do foolish things in every language ever created. -- That is not a reasonable position. If a function is written sensibly, the value can never be garbage. How could it be?
- maleldil 2y ago
  What does this even mean? If I read from a file that doesn't exist, what should the returned object be? Isn't the state of the file directly tied to the error? If I ignore the error and try to use the file anyway, the following operations wouldn't make sense. How can you read from a non-existent file?
  - 9rx 2y ago
    > If I read from a file that doesn't exist, what should the returned object be? First things first, how can you read from a file that doesn't exist? Even you questioned that later, so this is a strange question. – Do you mean if you try to open a file that doesn't exist? nil would be a reasonable value. It is how Go signifies the absence of something. nil is always useful and with `if file == nil` will tell you that the file isn't there. No need to observe the error. If you need to know why the file isn't there then, sure, you're also going to have to look at the error. Sometimes that is important. In the case of opening a file you realistically will need to know why it failed to open so that you can resolve the condition, but in other cases you don't need to worry about why it failed. Checking the error would be unnecessary in those cases, assuming the function author has some understanding of how to make even half-decent APIs. Let's assume here, for the sake of discussion, that you have no need to know why the file was unable to opened. Again, how do you envision garbage propagating into the rest of your program?
    - int_19h 2y ago
      Let's say you successfully opened a file, but it was on removable media which got ejected mid-read.
      - deleted 2y ago
        [deleted]
      - 9rx 2y ago
        You’d return -1. A successful read won’t read negative bytes. The non-error value remains useful.
        int_19h 2y ago
        That's actually a great example. Note that it is a distinct sentinel error value that needs to be checked for (contrary to your initial assertion), and if you forget to do it, you'll just end up with garbage. But also, let's say the read function in question is named ReadInt32. Then what does it return on error?

tubthumper8 2y ago

> But that is unnecessary in Go as it believes that values should always be useful – which means you don't need to even consider the error to use the value. Is this true? Are values always useful? You shouldn't even need to consider the error? For example, if GPS errored while calling an Uber, is it useful to ignore the error and instead display the Uber driver as being in the middle of the ocean? https://www.reddit.com/r/uberdrivers/comments/zjpv69/well_how_could_i_pass_up_this_ride/ https://www.reddit.com/r/uberdrivers/comments/zjpv69/well_ho...