2 ms·

it is my second or third favorite part of Go. What sucks more than just about anything is exceptions as control flow. It is a spooky GOTO at a distance. To eve

it is my second or third favorite part of Go. What sucks more than just about anything is exceptions as control flow. It is a spooky GOTO at a distance. To everyone who complains about the "if err != nil { return err }", honestly, you are doing it wrong or you have a toy application. I have written several, large, high scale, highly available systems processing multiple billions of requests a day. When analyizing those code bases, empty error returns like that accounted for 4% or less of our code. We always were doing _something_ with the error. Metrics, logging, reties, sending off to a different workstream, etc.

deagle50 3y ago
It's not just the empty return. It's that every fallible function call starts with `err = foo()` or `value, err = foo()`. You're forced to read `err` at the beginning of every function call even if you don't care. How will sugar for an empty return or appending an error handling scope harm anything?
- deagle50 3y ago
  And I understand the advantages over exceptions, but we've made some nice progress since the mid 2000s. Sum types and error unions aren't rocket science and even the assembly line programming model that Go seems to have built to enable could adopt them up in a day. You could even have `catch` capture only the last value in the result tuple and it would still be big improvement.
  - sethammons 3y ago
    sum types and pattern matching are great. For me, I'm anti-exception. "Point on the doll where the exceptions hurt you." I worked on a project with exceptions as control flow (cough, twisted python, cough), and the error handling was caught several classes and mixins up and over in the file directory. In some far away file, your exception triggered a callback or an errback, and if that excepted, similar magic happened. It got to the point that several engineering choices had to be made around "well, this really would be nice to have an exception and some standard handling, but the framework will take it and do strange things." I _love_ handling my errors where they are created.

deagle50 3y ago

It's not just the empty return. It's that every fallible function call starts with `err = foo()` or `value, err = foo()`. You're forced to read `err` at the beginning of every function call even if you don't care. How will sugar for an empty return or appending an error handling scope harm anything?

deagle50 3y ago
And I understand the advantages over exceptions, but we've made some nice progress since the mid 2000s. Sum types and error unions aren't rocket science and even the assembly line programming model that Go seems to have built to enable could adopt them up in a day. You could even have `catch` capture only the last value in the result tuple and it would still be big improvement.
- sethammons 3y ago
  sum types and pattern matching are great. For me, I'm anti-exception. "Point on the doll where the exceptions hurt you." I worked on a project with exceptions as control flow (cough, twisted python, cough), and the error handling was caught several classes and mixins up and over in the file directory. In some far away file, your exception triggered a callback or an errback, and if that excepted, similar magic happened. It got to the point that several engineering choices had to be made around "well, this really would be nice to have an exception and some standard handling, but the framework will take it and do strange things." I _love_ handling my errors where they are created.