5 ms·

Go is a little more verbose in basically two ways: it forces you to handle error states explicitly, and it doesn't let you do overly-clever things to save a few

Go is a little more verbose in basically two ways: it forces you to handle error states explicitly, and it doesn't let you do overly-clever things to save a few lines of typing. Neither of which increase the maintenance or testing burden.

jacques_chester 11y ago
> it forces you to handle error states explicitly, Does it? `if err != nil` is a convention. It's not a checked error. It's like saying "C has explicit array bounds checking", if the convention was to check it by hand. For all the hate Java gets, when I have a checked exception, I know what it is going to be. I don't need to dig around in sourcecode trying to work out if I should care or not. I don't need to check which of the three Golang error-distinction idioms (package-variable errors, error subtypes, plain-old-errors-with-magical-strings) is in play. As you can guess, I don't like Go.
- sagichmal 11y ago
  > `if err != nil` is a convention. It's not a checked error. It's... obviously both.
  - jacques_chester 11y ago
    Sorry, typo. "Checked exception", meaning that the compiler enforces error handling and that you can look a method signature and learn what kind of exceptions the method can throw without needing to read its internals.
- fooster 11y ago
  And runtime exceptions? What about them?
  - jacques_chester 11y ago
    They leave you in about the same position as a programmer in a dynamic language. The advantage of runtime exceptions over Go is that I will get a fatal crash and a stacktrace. I don't have computation proceeding in an undefined, difficult-to-debug way because I forgot to do `err != nil` somewhere (particularly for functions that only return err).
    - fooster 11y ago
      Or someone will catch it and discard the result which is often often what occurs. For example, with java throw an exception in an executor task (an assertion failure for example). What do you think occurs?
      - jacques_chester 11y ago
        Which happens in Go too. I've seen a lot of code that happily sails past functions which only return err, meaning the compiler never pipes up. Don't get me wrong, though. I become grumpy when I see empty catch clauses. Or a logger figleaf.
- superuser2 11y ago
  'err' is sitting there in the return value and the compiler will force you to either use it or explicitly steamroll it. The difference between C bounds checking and Go error checking is that you can't forget to check an error in Go.
  - azth 11y ago
    I guess everyone is remembering to check the return values of fmt.Println() then huh?
pcwalton 11y ago
> Go is a little more verbose in basically two ways: it forces you to handle error states explicitly No, it doesn't (simple example: the return value of os.Setenv). errcheck exists for a reason.
lmm 11y ago
Programming consists entirely of doing overly-clever things to save a few lines of typing. Go belongs to the same school of ludditery as von Neumann's opposition to assembly.
MichaelGG 11y ago
>doesn't let you do overly-clever things to save a few lines of typing So that's what we're calling the lack of HoFs these days? It's really sad to hear that anyone considers map/fold/filter are "overly-clever". Tim Sweeney (Epic) says[1]: "“For” loops in Unreal: 40% are functional comprehensions 50% are functional folds" I hardly see how changing those loops into a construct that more accurately represents them is overly-clever. 1: http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt
- burntsushi 11y ago
  > So that's what we're calling the lack of HoFs these days? Go has HoFs. The lack of parametric polymorphism is what prevents you from writing `map` in Go (subject to several caveats surrounding efficiency and type safety).
  - MichaelGG 11y ago
    In practise I don't find passing function parameters without generics to be very useful.

jacques_chester 11y ago

> it forces you to handle error states explicitly, Does it? `if err != nil` is a convention. It's not a checked error. It's like saying "C has explicit array bounds checking", if the convention was to check it by hand. For all the hate Java gets, when I have a checked exception, I know what it is going to be. I don't need to dig around in sourcecode trying to work out if I should care or not. I don't need to check which of the three Golang error-distinction idioms (package-variable errors, error subtypes, plain-old-errors-with-magical-strings) is in play. As you can guess, I don't like Go.

sagichmal 11y ago
> `if err != nil` is a convention. It's not a checked error. It's... obviously both.
- jacques_chester 11y ago
  Sorry, typo. "Checked exception", meaning that the compiler enforces error handling and that you can look a method signature and learn what kind of exceptions the method can throw without needing to read its internals.
fooster 11y ago
And runtime exceptions? What about them?
- jacques_chester 11y ago
  They leave you in about the same position as a programmer in a dynamic language. The advantage of runtime exceptions over Go is that I will get a fatal crash and a stacktrace. I don't have computation proceeding in an undefined, difficult-to-debug way because I forgot to do `err != nil` somewhere (particularly for functions that only return err).
  - fooster 11y ago
    Or someone will catch it and discard the result which is often often what occurs. For example, with java throw an exception in an executor task (an assertion failure for example). What do you think occurs?
    - jacques_chester 11y ago
      Which happens in Go too. I've seen a lot of code that happily sails past functions which only return err, meaning the compiler never pipes up. Don't get me wrong, though. I become grumpy when I see empty catch clauses. Or a logger figleaf.
superuser2 11y ago
'err' is sitting there in the return value and the compiler will force you to either use it or explicitly steamroll it. The difference between C bounds checking and Go error checking is that you can't forget to check an error in Go.
- azth 11y ago
  I guess everyone is remembering to check the return values of fmt.Println() then huh?

pcwalton 11y ago

> Go is a little more verbose in basically two ways: it forces you to handle error states explicitly No, it doesn't (simple example: the return value of os.Setenv). errcheck exists for a reason.

lmm 11y ago

Programming consists entirely of doing overly-clever things to save a few lines of typing. Go belongs to the same school of ludditery as von Neumann's opposition to assembly.

MichaelGG 11y ago

>doesn't let you do overly-clever things to save a few lines of typing So that's what we're calling the lack of HoFs these days? It's really sad to hear that anyone considers map/fold/filter are "overly-clever". Tim Sweeney (Epic) says[1]: "“For” loops in Unreal: 40% are functional comprehensions 50% are functional folds" I hardly see how changing those loops into a construct that more accurately represents them is overly-clever. 1: http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt

burntsushi 11y ago
> So that's what we're calling the lack of HoFs these days? Go has HoFs. The lack of parametric polymorphism is what prevents you from writing `map` in Go (subject to several caveats surrounding efficiency and type safety).
- MichaelGG 11y ago
  In practise I don't find passing function parameters without generics to be very useful.