4 ms·

Heh, production grade depends more on the people in charge than the tech choices. The lack of exceptions in Go is the biggest stupid thing in software. Except

Heh, production grade depends more on the people in charge than the tech choices. The lack of exceptions in Go is the biggest stupid thing in software. Exceptions have always been a much less risque feature than multiple return values. In Go every single "function" has multiple return values and the code is litered everywhere with if err != nil... garbage. It will never change because it is apparent that exceptions are to Go as collection literals and operator overloading are to Java.

jimktrains2 6y ago
Exceptions aren't the only way to handle error. Rust leverages algebraic types to good effect, for example.
sethammons 6y ago
I've worked in exception based code bases such as Python (Twisted specifically) and Go. Unlike many, I've used both in the same organization working on similar problems for nearly a decade while the scale of number of engineers working in the code and the number of requests it serves have gone up considerably. Hundreds of contributors. Billions of daily requests. I humbly suggest that indexing on the lack of exceptions as a quality measure is a poorly lacking criteria. Ditching exceptions in Twisted Python and porting code to Go has created vastly more readable, maintainable, and performant code in multiple cases for us.
- one2know 6y ago
  I understand golang was an attempt to fix c's shortcomings and not to create the next c++ or java. But I also understand programmers get their way of doing things that are bad. Case in point, people who do println("entering function doit()"); println ("exiting function doit()"); for every function in the entire codebase because it's how they learned to "debug" and they never tried anything better. Error returns in golang are like that. It has to be for every function in the codebase and balloons the code by a non-trivial percent. As for performant, as of at least ten years ago it became impossible for a person to perceive a performance increase by removing exception handling. A human can't perceive the microseconds.
  - erik_seaberg 6y ago
    Does go actually generate machine code that continually checks for err != nil? Because that can be more expensive than generating an unwind table and ignoring it until an exception actually happens.
  - sethammons 6y ago
    > As for performant, as of at least ten years ago it became impossible for a person to perceive a performance increase by removing exception handling. You are really hung up on the exception handling. I never claimed that the error handling made Go more performant. I wrote "performant" as in "there are other things that are important that should be taken into consideration aside from use of exceptions". It might not be as apparent to others now as you edited your original response that was along the lines of "not using exceptions is the worst software decision of all time." (note I don't recall the exact thing you wrote, but that feels close). As for the new edit you have: > litered everywhere with if err != nil... garbage I just grepped one of my Go code bases. It is 40,636 lines of code. It has 326 "if err !=" lines. Less than 1% of the lines are for error handling preamble, and we take our error handling very serious. In fact, a lot of those error checks don't directly bubble up. They perform fallback logic, logging and/or metrics, or set sane default values. Sure, some bubble up, but it is less than half as grep suggests 134 bubble up. What I value about local error checking is that everything you need is right in front of you as a reader of the code. When I worked in Twisted Python, one particularly bad case of exception handling made it so I literally could not use ErrBacks in one part of the code because in some other module someone used an exception for a non-exceptional error.
jatone 6y ago
sounds like someone is too focused on aesthetics instead of maintainable code. exceptions have far worse impacts than multiple returns and if statements to check. particularly that they are basically new age gotos. throw an exception, up and up and up it goes where it stops who knows!
- one2know 6y ago
  That's funny because Java devs for decades said that multiple returns and tons of if statement trees were the codings of satan. I am doing golang code right now and all I see are pages and pages of "if err != nil {" or "if err := doSomething(); err {". Oops I forgot to check err, guess my code is not as maintainable and my process is going to panic and die in the middle of a request. Guess I will write a defer-recover for every function in the call stack. Sure wish there was some handy notation to make it easier to try that and catch the failure, wink wink. Every generation has their plaid pants. For c programmers it was ASCII art box headers for every file and function. For C# it was IMySuperLongClassInterfaceTypeOLEActiveXInterface. For java it is no collection literals, operator overloading, and fights over lambdas for a decade. For golang it is error return values EDIT: and also no generics/templates.

jimktrains2 6y ago

Exceptions aren't the only way to handle error. Rust leverages algebraic types to good effect, for example.

sethammons 6y ago

I've worked in exception based code bases such as Python (Twisted specifically) and Go. Unlike many, I've used both in the same organization working on similar problems for nearly a decade while the scale of number of engineers working in the code and the number of requests it serves have gone up considerably. Hundreds of contributors. Billions of daily requests. I humbly suggest that indexing on the lack of exceptions as a quality measure is a poorly lacking criteria. Ditching exceptions in Twisted Python and porting code to Go has created vastly more readable, maintainable, and performant code in multiple cases for us.

one2know 6y ago
I understand golang was an attempt to fix c's shortcomings and not to create the next c++ or java. But I also understand programmers get their way of doing things that are bad. Case in point, people who do println("entering function doit()"); println ("exiting function doit()"); for every function in the entire codebase because it's how they learned to "debug" and they never tried anything better. Error returns in golang are like that. It has to be for every function in the codebase and balloons the code by a non-trivial percent. As for performant, as of at least ten years ago it became impossible for a person to perceive a performance increase by removing exception handling. A human can't perceive the microseconds.
- erik_seaberg 6y ago
  Does go actually generate machine code that continually checks for err != nil? Because that can be more expensive than generating an unwind table and ignoring it until an exception actually happens.
- sethammons 6y ago
  > As for performant, as of at least ten years ago it became impossible for a person to perceive a performance increase by removing exception handling. You are really hung up on the exception handling. I never claimed that the error handling made Go more performant. I wrote "performant" as in "there are other things that are important that should be taken into consideration aside from use of exceptions". It might not be as apparent to others now as you edited your original response that was along the lines of "not using exceptions is the worst software decision of all time." (note I don't recall the exact thing you wrote, but that feels close). As for the new edit you have: > litered everywhere with if err != nil... garbage I just grepped one of my Go code bases. It is 40,636 lines of code. It has 326 "if err !=" lines. Less than 1% of the lines are for error handling preamble, and we take our error handling very serious. In fact, a lot of those error checks don't directly bubble up. They perform fallback logic, logging and/or metrics, or set sane default values. Sure, some bubble up, but it is less than half as grep suggests 134 bubble up. What I value about local error checking is that everything you need is right in front of you as a reader of the code. When I worked in Twisted Python, one particularly bad case of exception handling made it so I literally could not use ErrBacks in one part of the code because in some other module someone used an exception for a non-exceptional error.

jatone 6y ago

sounds like someone is too focused on aesthetics instead of maintainable code. exceptions have far worse impacts than multiple returns and if statements to check. particularly that they are basically new age gotos. throw an exception, up and up and up it goes where it stops who knows!

one2know 6y ago
That's funny because Java devs for decades said that multiple returns and tons of if statement trees were the codings of satan. I am doing golang code right now and all I see are pages and pages of "if err != nil {" or "if err := doSomething(); err {". Oops I forgot to check err, guess my code is not as maintainable and my process is going to panic and die in the middle of a request. Guess I will write a defer-recover for every function in the call stack. Sure wish there was some handy notation to make it easier to try that and catch the failure, wink wink. Every generation has their plaid pants. For c programmers it was ASCII art box headers for every file and function. For C# it was IMySuperLongClassInterfaceTypeOLEActiveXInterface. For java it is no collection literals, operator overloading, and fights over lambdas for a decade. For golang it is error return values EDIT: and also no generics/templates.