4 ms·

I don't see why that wouldn't be possible to implement now that the generics are here.

linkdd 5y ago
Which is exactly why I said: > I cannot wait for the Result monad. Generics make this possible, and will be a huge improvement to Go's error handling. I'm not saying it will solve everything, but it's a huge step nonetheless.
- egeozcan 5y ago
  I seem to have lost track of how the discussion reached that point, thanks for the clarification.
- xyzzy_plugh 5y ago
  I think you will find that Go's error handling will not change as much as you suggest. The majority of developers are extremely cautious of generics and found the status quo to be the best balance between readability and conciseness. Convenience is not a goal of the language, generally.
  - Aeolun 5y ago
    It doesn’t need to be part of the core language. Everyone can make their own monad, or use the one from a library.
  - saghm 5y ago
    > The majority of developers are extremely cautious of generics and found the status quo to be the best balance between readability and conciseness. Most people who use Go have specifically chosen to use it though (or at least sought out opportunities, given that it's not something entrenched like Java being used due to inertia), so yes, most of them are fine with how Go is or they wouldn't be using it in the first place. If Go had generics from the start, I'd imagine most users would be fine with that too due to self-selection.
eru 5y ago
Depends on how generic you want this. In Haskell, you can have functions that work generically over option-types, error-able types, lists, functions, tuples, etc. In Rust, you have to specifically implement functionality for all of these. But eg your 'map' function in Rust still works for all lists, no matter what item type. In Go before this change, you had to write a different map function for each item type that could be in your list. In Haskell, the same 'map' function works for lists, functions, error-able types etc.

Which is exactly why I said: > I cannot wait for the Result monad. Generics make this possible, and will be a huge improvement to Go's error handling. I'm not saying it will solve everything, but it's a huge step nonetheless.

egeozcan 5y ago
I seem to have lost track of how the discussion reached that point, thanks for the clarification.
xyzzy_plugh 5y ago
I think you will find that Go's error handling will not change as much as you suggest. The majority of developers are extremely cautious of generics and found the status quo to be the best balance between readability and conciseness. Convenience is not a goal of the language, generally.
- Aeolun 5y ago
  It doesn’t need to be part of the core language. Everyone can make their own monad, or use the one from a library.
- saghm 5y ago
  > The majority of developers are extremely cautious of generics and found the status quo to be the best balance between readability and conciseness. Most people who use Go have specifically chosen to use it though (or at least sought out opportunities, given that it's not something entrenched like Java being used due to inertia), so yes, most of them are fine with how Go is or they wouldn't be using it in the first place. If Go had generics from the start, I'd imagine most users would be fine with that too due to self-selection.

eru 5y ago

Depends on how generic you want this. In Haskell, you can have functions that work generically over option-types, error-able types, lists, functions, tuples, etc. In Rust, you have to specifically implement functionality for all of these. But eg your 'map' function in Rust still works for all lists, no matter what item type. In Go before this change, you had to write a different map function for each item type that could be in your list. In Haskell, the same 'map' function works for lists, functions, error-able types etc.