4 ms·

The huge volume of boilerplate makes the code harder to read, and annoying to write. I like go, and I don’t want exceptions persay, but I would love something t

The huge volume of boilerplate makes the code harder to read, and annoying to write. I like go, and I don’t want exceptions persay, but I would love something that cuts out all the repetitive noise.

jacobr1 2y ago
The example in the article is a good one. Result and Optional as first class sum types
- RedComet 2y ago
  That just changes the boilerplate from if's to match's.
  - Mawr 2y ago
    See the example with the `?` operator: https://github.com/borgo-lang/borgo?tab=readme-ov-file#error-handling-with--operator https://github.com/borgo-lang/borgo?tab=readme-ov-file#error... The main benefits of a Result type are brevity and the inability to accidentally not handle an error.
    - RedComet 2y ago
      Yes, but that isn't necessarily a feature of option types. Is it the case that similar sugar for the tiresome Go pattern couldn't achieve similar benefits?
      - Mawr 2y ago
        Perhaps, but there have been several proposals along those lines and nobody seems capable of figuring out a sensible implementation. A funny drawback of the current Go design that a Result type would solve is the need to return zero values of all the declared function return types along with the error: https://github.com/golang/go/issues/21182 https://github.com/golang/go/issues/21182.
  - BillyTheKing 2y ago
    exactly.. yes, I understand why ? is neat from a type POV since you specifically have to unwrap an optional type whereas in Go you can ignore a returned error (although linters catch that) - so at the end of the day it's just the same boilerplate, one with ? the other with err != nil
throwaway894345 2y ago
This has not been my experience. It doesn’t make the code harder to read, but it forces you to think about all the code paths—if you only care about one code path, the error paths may feel like “noise”, but that’s Go guiding you toward better engineering practices. It’s the same way JavaScript developers felt when TypeScript came along and made it painful to write buggy code—the tools guide you toward better practices.
demi56 2y ago
> The huge volume of boilerplate makes the code harder to read, and annoying to write That may be superficially true but don’t forget our brain is structured to optimize every repetitive work or some boilerplates, we can basically use “strcpy” and “string_copy” we are so used to all these that even if repeated a billion times it can be processed fast

jacobr1 2y ago

The example in the article is a good one. Result and Optional as first class sum types

RedComet 2y ago
That just changes the boilerplate from if's to match's.
- Mawr 2y ago
  See the example with the `?` operator: https://github.com/borgo-lang/borgo?tab=readme-ov-file#error-handling-with--operator https://github.com/borgo-lang/borgo?tab=readme-ov-file#error... The main benefits of a Result type are brevity and the inability to accidentally not handle an error.
  - RedComet 2y ago
    Yes, but that isn't necessarily a feature of option types. Is it the case that similar sugar for the tiresome Go pattern couldn't achieve similar benefits?
    - Mawr 2y ago
      Perhaps, but there have been several proposals along those lines and nobody seems capable of figuring out a sensible implementation. A funny drawback of the current Go design that a Result type would solve is the need to return zero values of all the declared function return types along with the error: https://github.com/golang/go/issues/21182 https://github.com/golang/go/issues/21182.
- BillyTheKing 2y ago
  exactly.. yes, I understand why ? is neat from a type POV since you specifically have to unwrap an optional type whereas in Go you can ignore a returned error (although linters catch that) - so at the end of the day it's just the same boilerplate, one with ? the other with err != nil

throwaway894345 2y ago

This has not been my experience. It doesn’t make the code harder to read, but it forces you to think about all the code paths—if you only care about one code path, the error paths may feel like “noise”, but that’s Go guiding you toward better engineering practices. It’s the same way JavaScript developers felt when TypeScript came along and made it painful to write buggy code—the tools guide you toward better practices.

demi56 2y ago

> The huge volume of boilerplate makes the code harder to read, and annoying to write That may be superficially true but don’t forget our brain is structured to optimize every repetitive work or some boilerplates, we can basically use “strcpy” and “string_copy” we are so used to all these that even if repeated a billion times it can be processed fast