6 ms·

I disliked it initially. After 5-6 years of using Go as my primary language I’ve come to appreciate it. It is clearer than having to figure out what is returned

by bborud 5y ago

I disliked it initially. After 5-6 years of using Go as my primary language I’ve come to appreciate it. It is clearer than having to figure out what is returned. And if an error can be returned. It’s easier when it is right there in the function signature.

Zababa 5y ago
The thing sum types would allow is to make a clear distinction between functions that return either a result or an error and functions that can return both a result and an error. Many functions in Go will always return either res, nil or nil, err. Those functions would benefit from a way to show that in the signature, to differentiate them from the functions that can return res, err at the same time. This is not a replacement for multiple return values, as there are many cases where multiple return value are useful.
monocasa 5y ago
But a Result<foo*, error> is clearer than foo*, error. I think that's the point the parent is making.
- kadoban 5y ago
  Exactly, at least it's clearer in the vast majority of cases where that's what I actually mean (but golang won't let me encode easily). The way golang ~makes me encodes it makes using these functions annoying, because then you ~need to test for the nonsense cases where you have neither an error or a result, and maybe where you have both.
  - bborud 5y ago
    But how is it clearer? I can see the point of where you get neither error nor result, but you can get that in both scenarios, so I don't see how anything is gained. And you still have the same burden of checking whether an error condition did arise. That is the bit that usually matters when you call a function: knowing if it has error conditions (many functions don't) and checking if/what they are. I don't see any practical advantage here. Explain it to me like I'm five :)
    - lmm 5y ago
      > I can see the point of where you get neither error nor result, but you can get that in both scenarios No you can't? The whole point of a sum type is that it's definitely exactly one of a result or an error; the language will not let it be both or neither.
      - bborud 5y ago
        Look at it from the receiving end: you are calling a function and you need to decide what to do with the response. The only thing that's different is that you get a single value you have to check for errors rather than a separate value. It is the same amount of code. I can appreciate that people interested in language design think this is an important distinction, but in practice it really doesn't make a huge difference when you consume an API. And if we move to the more general case, where a function in essence has multiple return types (albeit narrowed to a set of possible types), you still end up with something akin to a type switch. Yes, you can skip a default clause and you can have the compiler complain if you don't handle all types explicitly, but it is unclear to me if that doesn't just create new kinds of annoyances. (I deal a lot with sum types in Protobuffers and it isn't always as nice as I had hoped. In fact, I use them for entirely different reasons than correctness and clarity)
        lmm 5y ago
        I'm coming at it solely on the basis of practical experience. Removing a single boilerplate check might seem insignificant, but it compounds: when these types are lightweight to work with you can extract more tiny helper functions, and then you have a whole vocabulary of common operations / ways of doing composition, and you can write these really readable functions that just get all the plumbing out the way (but without making it completely invisible) and let you focus on the business logic.
        wlamartin 5y ago
        > The only thing that's different is that you get a single value you have to check for errors rather than a separate value.. The type system confines you to a set of reasonable cases that allow a caller to reason about the state of the program. This has two benefits for the caller: 1. It is required that the caller check whether a return value is success or failure in order to access the value they want. There is no possibility to mistake one case for another. 2. In the space of valid return values for idiomatic Go function signatures, 50% of them are unidiomatic and end up being ignored. It is far clearer for a caller to understand what is expected of them when valid values exactly overlap with the space. It is far clearer for an author to convey expectations to a caller for the same reason. Now I must admit, good conventions and tooling in Go account for the vast majority of cases and I don't personally mind that much, but that's a different conversation than API design.
- bborud 5y ago
  Yes, and the point I was making was that I don't think it actually makes things much clearer. One has more syntax and alters the effective return value, the other just states what you will get back regardless of result. From a practical point of view when you are consuming an API, which requires more concentration?
  - Zababa 5y ago
    > From a practical point of view when you are consuming an API, which requires more concentration? I think the current Go one requires more concentration, or at least more work. Lots of functions return data, err. You have to check for each of these functions if the presence of err means that data is going to be invalid/nil or add it to your code. The same argument could be made for nil by the way. Since everything can be nil, you have to check for nil often. In languages that make a difference between a type, and a type or nil, this is easier.
  - monocasa 5y ago
    The one that doesn't attempt to tell me which will be valid in relation to eachother, so I have to go divine that rather than just reading the function signature?
baby 5y ago
I don't think it's clearer personally, but the problem is really that it's not secure. If you forget to check the `err` (or the `nil`) then you might shoot yourself in the foot. As a pentester, most of the bugs I found in Golang codebases would have been avoided with sum types.
BobbyJo 5y ago
I can't count the number of times this has forced me to make a better interface/abstraction that the one I was making. It's too bad this idiom is going to be the 'wrong way' to do things soon, because, for some reason, every code Guru out there thinks number of characters/lines is the single defining cost function for software maintenance, and that's who the kids coming out of college are going to listen to.
- kadoban 5y ago
  It's just fundamentally the wrong type for what it's supposed to represent. What I'd prefer isn't any more concise in lines or characters, it simply actually represents what it's supposed to. "a*, error" has 4 different members, if you consider just "exists" vs "doesn't exist" for each. Of those, "nil, nil" and "&a{}, errors.New("whatever")" are broken. Fully half of the things you can represent are just wrong. (Yes there are times when those are valid returns, but easily 99% of the time they're not. The type system should be able to represent both ways.)
  - BobbyJo 5y ago
    > The type system should be able to represent both ways. Go's type system can already do that, the (x, error) idiom is just standard practice in the absence of Generics and Throwables. Adding generics simply flips the default and exception. Currently, the exception is to define a custom type which captures and constrains your possible return states, and the default is to return a value plus an error. When that flips, and the default is to collapse error states into a single return value, that will cease to give me the same signals (or at least make them less obvious) as to whether or not my abstraction sucks, which I will sorely miss :P
    - kadoban 5y ago
      How does go's type system allow the "exactly one of these two" case? What's the syntax?
      - BobbyJo 5y ago
OceanSpray 5y ago
Are you implying that sum types wouldn't be expressed in a function signature?
- bborud 5y ago
  No, I'm pointing out that some functions don't return errors.

by bborud 5y ago

Zababa 5y ago

The thing sum types would allow is to make a clear distinction between functions that return either a result or an error and functions that can return both a result and an error. Many functions in Go will always return either res, nil or nil, err. Those functions would benefit from a way to show that in the signature, to differentiate them from the functions that can return res, err at the same time. This is not a replacement for multiple return values, as there are many cases where multiple return value are useful.

monocasa 5y ago

But a Result<foo*, error> is clearer than foo*, error. I think that's the point the parent is making.

kadoban 5y ago
Exactly, at least it's clearer in the vast majority of cases where that's what I actually mean (but golang won't let me encode easily). The way golang ~makes me encodes it makes using these functions annoying, because then you ~need to test for the nonsense cases where you have neither an error or a result, and maybe where you have both.
- bborud 5y ago
  But how is it clearer? I can see the point of where you get neither error nor result, but you can get that in both scenarios, so I don't see how anything is gained. And you still have the same burden of checking whether an error condition did arise. That is the bit that usually matters when you call a function: knowing if it has error conditions (many functions don't) and checking if/what they are. I don't see any practical advantage here. Explain it to me like I'm five :)
  - lmm 5y ago
    > I can see the point of where you get neither error nor result, but you can get that in both scenarios No you can't? The whole point of a sum type is that it's definitely exactly one of a result or an error; the language will not let it be both or neither.
    - bborud 5y ago
      Look at it from the receiving end: you are calling a function and you need to decide what to do with the response. The only thing that's different is that you get a single value you have to check for errors rather than a separate value. It is the same amount of code. I can appreciate that people interested in language design think this is an important distinction, but in practice it really doesn't make a huge difference when you consume an API. And if we move to the more general case, where a function in essence has multiple return types (albeit narrowed to a set of possible types), you still end up with something akin to a type switch. Yes, you can skip a default clause and you can have the compiler complain if you don't handle all types explicitly, but it is unclear to me if that doesn't just create new kinds of annoyances. (I deal a lot with sum types in Protobuffers and it isn't always as nice as I had hoped. In fact, I use them for entirely different reasons than correctness and clarity)
      - lmm 5y ago
        I'm coming at it solely on the basis of practical experience. Removing a single boilerplate check might seem insignificant, but it compounds: when these types are lightweight to work with you can extract more tiny helper functions, and then you have a whole vocabulary of common operations / ways of doing composition, and you can write these really readable functions that just get all the plumbing out the way (but without making it completely invisible) and let you focus on the business logic.
      - wlamartin 5y ago
        > The only thing that's different is that you get a single value you have to check for errors rather than a separate value.. The type system confines you to a set of reasonable cases that allow a caller to reason about the state of the program. This has two benefits for the caller: 1. It is required that the caller check whether a return value is success or failure in order to access the value they want. There is no possibility to mistake one case for another. 2. In the space of valid return values for idiomatic Go function signatures, 50% of them are unidiomatic and end up being ignored. It is far clearer for a caller to understand what is expected of them when valid values exactly overlap with the space. It is far clearer for an author to convey expectations to a caller for the same reason. Now I must admit, good conventions and tooling in Go account for the vast majority of cases and I don't personally mind that much, but that's a different conversation than API design.
bborud 5y ago
Yes, and the point I was making was that I don't think it actually makes things much clearer. One has more syntax and alters the effective return value, the other just states what you will get back regardless of result. From a practical point of view when you are consuming an API, which requires more concentration?
- Zababa 5y ago
  > From a practical point of view when you are consuming an API, which requires more concentration? I think the current Go one requires more concentration, or at least more work. Lots of functions return data, err. You have to check for each of these functions if the presence of err means that data is going to be invalid/nil or add it to your code. The same argument could be made for nil by the way. Since everything can be nil, you have to check for nil often. In languages that make a difference between a type, and a type or nil, this is easier.
- monocasa 5y ago
  The one that doesn't attempt to tell me which will be valid in relation to eachother, so I have to go divine that rather than just reading the function signature?

baby 5y ago

I don't think it's clearer personally, but the problem is really that it's not secure. If you forget to check the `err` (or the `nil`) then you might shoot yourself in the foot. As a pentester, most of the bugs I found in Golang codebases would have been avoided with sum types.

BobbyJo 5y ago

I can't count the number of times this has forced me to make a better interface/abstraction that the one I was making. It's too bad this idiom is going to be the 'wrong way' to do things soon, because, for some reason, every code Guru out there thinks number of characters/lines is the single defining cost function for software maintenance, and that's who the kids coming out of college are going to listen to.

kadoban 5y ago
It's just fundamentally the wrong type for what it's supposed to represent. What I'd prefer isn't any more concise in lines or characters, it simply actually represents what it's supposed to. "a*, error" has 4 different members, if you consider just "exists" vs "doesn't exist" for each. Of those, "nil, nil" and "&a{}, errors.New("whatever")" are broken. Fully half of the things you can represent are just wrong. (Yes there are times when those are valid returns, but easily 99% of the time they're not. The type system should be able to represent both ways.)
- BobbyJo 5y ago
  > The type system should be able to represent both ways. Go's type system can already do that, the (x, error) idiom is just standard practice in the absence of Generics and Throwables. Adding generics simply flips the default and exception. Currently, the exception is to define a custom type which captures and constrains your possible return states, and the default is to return a value plus an error. When that flips, and the default is to collapse error states into a single return value, that will cease to give me the same signals (or at least make them less obvious) as to whether or not my abstraction sucks, which I will sorely miss :P
  - kadoban 5y ago
    How does go's type system allow the "exactly one of these two" case? What's the syntax?
    - BobbyJo 5y ago

OceanSpray 5y ago

Are you implying that sum types wouldn't be expressed in a function signature?

bborud 5y ago
No, I'm pointing out that some functions don't return errors.