3 ms·

The point is to stay on topic. In what way do you believe sum types solve the problem being discussed?

vacuity 3y ago
If you're going to invoke some abstract "the programmer doesn't know what they're doing" situation, I'm not sure how to continue this discussion. Even testing may not help in that case. Things are going to slip through the cracks. Having features like sum types is a way to generally reduce the likelihood of such semantic errors. Besides, the original topic was that Go doesn't make its error handling very foolproof. Sum types help with that and don't make error handling special, so I really don't see your point. Why not write everything in Brainfuck then? Everything is uniform and simple. Well, it's simple to the point that it's way too easy to make mistakes.
- randomdata 3y ago
  The original topic was, stated quite explicitly, that it is easy to forget to handle errors in Go. There is nothing about sum types, as defined, that addresses that concern. Like we established in my very first comment, well before you even showed up, the handling forgetfulness problem exists for all types. That would include a hypothetical (tagged) union type. I did question if you were using some other definition of sum types, as there isn't a great consensus on what sum types actually mean, but you did confirm you were thinking of tagged unions... But it must be that you didn't actually mean tagged unions. What is the definition of sum types that you are using here that would help with the stated problem?
  - vacuity 3y ago
    There may be a misunderstanding. I say "sum type" to mean something along the lines of Rust's enum: a value stores both a tag and its data, and pattern matching distinguishes the variants (like a switch statement). It's a tagged union where the interpretation of the tag is managed by the compiler. The underlying value can't be used without extracting the variant with pattern matching. Even if the success and failure variants both contain an integer, you can't add an integer with this value.
    - randomdata 3y ago
      And how do you think that solves the problem? Consider: func foo() error With the programmer forgetting to handle the error: foo() Now imagine that Go received some kind of hypothetical Result type. The foo function is updated to use it: func foo() Result[error] But the problem remains. The compiler still isn't going to tell you that you forgot to handle the error.
      - vacuity 3y ago
        So you're saying the programmer forgets to use the return value at all. There are linters, documentation, and basic common sense. This is not at all a relevant issue, or else there are serious issues with the programs you see. Why are you discussing whether Go's error handling needs improvement if your imagined programmer can't even program? Well, I've spent enough time on this thread.
        deleted 3y ago
        [deleted]
        randomdata 3y ago
        > So you're saying the programmer forgets to use the return value at all. That's what the original commenter said. Logically, how else could you forget to handle the error? The compiler will bitch and moan if you do capture the result and then don't do anything with it. You did take the time to read the thread before replying, yes? > This is not at all a relevant issue It must be, else how do you explain the many comments you wrote trying to explain how sum types solves the problem? Even while I continually told you they don't. > Why are you discussing whether Go's error handling needs improvement if your imagined programmer can't even program? I said that it doesn't need improvement because in practice your tests will catch the problem immediately anyway. I even said that it is probably fundamentally impossible for there to be technical solution to the problem. And the rest of the time was telling you that sum types cannot solve the problem, despite your constant urging. I am still not clear how you think sum types solve the problem. > Well, I've spent enough time on this thread. Are you sure you spent any time on this thread?

If you're going to invoke some abstract "the programmer doesn't know what they're doing" situation, I'm not sure how to continue this discussion. Even testing may not help in that case. Things are going to slip through the cracks. Having features like sum types is a way to generally reduce the likelihood of such semantic errors. Besides, the original topic was that Go doesn't make its error handling very foolproof. Sum types help with that and don't make error handling special, so I really don't see your point. Why not write everything in Brainfuck then? Everything is uniform and simple. Well, it's simple to the point that it's way too easy to make mistakes.

randomdata 3y ago
The original topic was, stated quite explicitly, that it is easy to forget to handle errors in Go. There is nothing about sum types, as defined, that addresses that concern. Like we established in my very first comment, well before you even showed up, the handling forgetfulness problem exists for all types. That would include a hypothetical (tagged) union type. I did question if you were using some other definition of sum types, as there isn't a great consensus on what sum types actually mean, but you did confirm you were thinking of tagged unions... But it must be that you didn't actually mean tagged unions. What is the definition of sum types that you are using here that would help with the stated problem?
- vacuity 3y ago
  There may be a misunderstanding. I say "sum type" to mean something along the lines of Rust's enum: a value stores both a tag and its data, and pattern matching distinguishes the variants (like a switch statement). It's a tagged union where the interpretation of the tag is managed by the compiler. The underlying value can't be used without extracting the variant with pattern matching. Even if the success and failure variants both contain an integer, you can't add an integer with this value.
  - randomdata 3y ago
    And how do you think that solves the problem? Consider: func foo() error With the programmer forgetting to handle the error: foo() Now imagine that Go received some kind of hypothetical Result type. The foo function is updated to use it: func foo() Result[error] But the problem remains. The compiler still isn't going to tell you that you forgot to handle the error.
    - vacuity 3y ago
      So you're saying the programmer forgets to use the return value at all. There are linters, documentation, and basic common sense. This is not at all a relevant issue, or else there are serious issues with the programs you see. Why are you discussing whether Go's error handling needs improvement if your imagined programmer can't even program? Well, I've spent enough time on this thread.
      - deleted 3y ago
        [deleted]
      - randomdata 3y ago
        > So you're saying the programmer forgets to use the return value at all. That's what the original commenter said. Logically, how else could you forget to handle the error? The compiler will bitch and moan if you do capture the result and then don't do anything with it. You did take the time to read the thread before replying, yes? > This is not at all a relevant issue It must be, else how do you explain the many comments you wrote trying to explain how sum types solves the problem? Even while I continually told you they don't. > Why are you discussing whether Go's error handling needs improvement if your imagined programmer can't even program? I said that it doesn't need improvement because in practice your tests will catch the problem immediately anyway. I even said that it is probably fundamentally impossible for there to be technical solution to the problem. And the rest of the time was telling you that sum types cannot solve the problem, despite your constant urging. I am still not clear how you think sum types solve the problem. > Well, I've spent enough time on this thread. Are you sure you spent any time on this thread?