4 ms·

There seems to be no consensus as to what sum types actually means, but the most popular definition I find in my travels is: Tagged unions. Which is funny as a

There seems to be no consensus as to what sum types actually means, but the most popular definition I find in my travels is: Tagged unions. Which is funny as a sum is not a union, but anyway... Assuming you share in that definition, while Go might benefit from tagged unions in general, I'm not sure they actually help in any way with remember to handle errors. A union is just as easy to forget to handle as a single discriminate type. But perhaps you are of another sum type school? Perhaps one of the other sum type definitions are useful here?

vacuity 3y ago
Tagged union is a good definition. I was thinking of Rust's Result type, which has Ok(some value) and Err(some value) variants.
- randomdata 3y ago
  Right. See that doesn't help, at least not in the context of Go without any other modifications. Logically, you can reduce that Result state to a simple boolean (Ok = true, Err = false). But the bool type in Go is prone to the very same problem. It doesn't matter how many type layers you add. The problem is that there is nothing in the language that enforces handling of values, no matter what type that value might be.
  - vacuity 3y ago
    Yes, manual tagging doesn't provide type safety. That's why I said some people are disappointed that Go doesn't have sum types. There isn't even a convoluted workaround either, at least not a full one.
    - randomdata 3y ago
      It is not so much a matter of lack of type safety, it is forgetting to implement an application requirement. Even an advanced type system capable of formal proofs isn't going to help you if you've forgotten the requirement when defining the types. And if you are using a language with a lesser type system (Go, Rust, any language you are likely to use in the real word), and haven't forgotten the requirement, then you would have encoded that knowledge in tests instead, making the forgetfulness in implementation ultimately immaterial. After all, there is no practical difference between learning that you forgot to implement logic by the compiler telling you or the test suite telling you. So, we can infer that the OP is talking about where one straight up forgot about the requirement from start to finish. I'm skeptical that there is any technical solution to that problem, but sum types most certainly isn't it.
      - vacuity 3y ago
        There is a point at which even dependent typing won't save you, but sum types are a useful tool to reduce negligence. Don't let perfect be the enemy of good.
        randomdata 3y ago
        Sum types are useful tool, but they are not helpful in this particular case. There is nothing about sum types that would help avoid this problem in the slightest. Perfect need not be the enemy of good, but good is not equivalent to not even trying. This is not a general "wouldn't it be nice of Go had..." thread. We are talking about a specific problem.
        vacuity 3y ago
        I'm not really sure what your point is then. We should have comprehensive tests and therefore error checking isn't special compared to other programming mistakes? I think we should both have tests (don't skimp on them if given time, of course) and use tools like sum types to write more robust programs from the get-go. Errors can even be treated like other values using sum types; that raises the bar universally instead of just improving error checking.
        randomdata 3y ago
        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.

vacuity 3y ago

Tagged union is a good definition. I was thinking of Rust's Result type, which has Ok(some value) and Err(some value) variants.

randomdata 3y ago
Right. See that doesn't help, at least not in the context of Go without any other modifications. Logically, you can reduce that Result state to a simple boolean (Ok = true, Err = false). But the bool type in Go is prone to the very same problem. It doesn't matter how many type layers you add. The problem is that there is nothing in the language that enforces handling of values, no matter what type that value might be.
- vacuity 3y ago
  Yes, manual tagging doesn't provide type safety. That's why I said some people are disappointed that Go doesn't have sum types. There isn't even a convoluted workaround either, at least not a full one.
  - randomdata 3y ago
    It is not so much a matter of lack of type safety, it is forgetting to implement an application requirement. Even an advanced type system capable of formal proofs isn't going to help you if you've forgotten the requirement when defining the types. And if you are using a language with a lesser type system (Go, Rust, any language you are likely to use in the real word), and haven't forgotten the requirement, then you would have encoded that knowledge in tests instead, making the forgetfulness in implementation ultimately immaterial. After all, there is no practical difference between learning that you forgot to implement logic by the compiler telling you or the test suite telling you. So, we can infer that the OP is talking about where one straight up forgot about the requirement from start to finish. I'm skeptical that there is any technical solution to that problem, but sum types most certainly isn't it.
    - vacuity 3y ago
      There is a point at which even dependent typing won't save you, but sum types are a useful tool to reduce negligence. Don't let perfect be the enemy of good.
      - randomdata 3y ago
        Sum types are useful tool, but they are not helpful in this particular case. There is nothing about sum types that would help avoid this problem in the slightest. Perfect need not be the enemy of good, but good is not equivalent to not even trying. This is not a general "wouldn't it be nice of Go had..." thread. We are talking about a specific problem.
        vacuity 3y ago
        I'm not really sure what your point is then. We should have comprehensive tests and therefore error checking isn't special compared to other programming mistakes? I think we should both have tests (don't skimp on them if given time, of course) and use tools like sum types to write more robust programs from the get-go. Errors can even be treated like other values using sum types; that raises the bar universally instead of just improving error checking.
        randomdata 3y ago
        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.