4 ms·

> if err != nil is the feature, not the bug. It forces you to look at every place something can go wrong and decide what to do about it. No it really doesn't.

> if err != nil is the feature, not the bug. It forces you to look at every place something can go wrong and decide what to do about it. No it really doesn't. It litters your code with if statements that are all just about the same, except that one that needs to be different, and you go blind looking at them all and can't spot the difference. And these days people probably just type "tab" and their LLM assistant fills out the entire block incorrectly in one keypress copying the pattern from everything else. But LLMs didn't create that problem. Having to type something never meant you had to think about it, or thousands of "sudo shutdown -r now" commands would never have been run on production databases, because typing "sudo" would have magically made someone think about it, rather than just being keyboard memory. And the problem of reviewing the code and spotting the one error handling block that should be different from all the others is always going to be there for human reviewers. Rust converts the common case boilerplate down into one character: ? which lets you focus on any exceptional error handling rather than a wall of if statements that almost all look alike. And the compiler can see that you're ignoring a Result from a function call and force you to explicitly do something about. Plus you can then use a monad without knowing a single thing about monoids, endofuctors or category theory, and impress your friends.

potato-peeler 5mo ago
> No it really doesn't. It litters your code with if statements that are all just about the same Wrong thing to be bothered with. This allows static analysis of every possible path the code can take. Try to do that with throw/catch. There is a reason many industry guidelines like misra, jsf, etc just outright ban hidden paths. They have been literally catastrophic. There is a reason why many modern languages like go, rust, etc, want errors to be explicitly handled. Go documentation specifically reasons why they treat errors-as-values and why is it like that - https://go.dev/doc/faq#exceptions https://go.dev/doc/faq#exceptions > Rust converts the common case boilerplate down into one character: ? which lets you focus on any exceptional error handling rather than a wall of if statements that almost all look alike Again, wrong way to look at errors. Errors are not a problem for a compiler to resolve. Errors are part of your business logic. They need to be explicit and handled. The syntax of one language vs another is not the point of error handling. Errors are not a distraction. It is your job to review each path the code can take. Code may be written once, but code is always reviewed or audited or referenced more than once. No one is impressed if you write some meta magic one-liner. I would rather be more impressed if I can read your code and form a mental image on how many paths your code takes to achieve an outcome in a single sitting, instead of pinging you for a quick call to explain yourself. > you go blind looking at them all and can't spot the difference > And these days people probably just type "tab" and their LLM assistant fills out the entire block incorrectly in one keypress copying the pattern from everything else Now, if someone is 'going blind' looking at error checks, its because their function is doing too much and has too many failure points. Perhaps one may need to focus on honing their software engineering skills on how to structure their code, instead of hitting that 'tab' more so often.
- jesseschalken 5mo ago
  Go has plenty of hidden code paths in defer, panic and recover. You can minimise the use of those things, just like in other languages you can minimise use of try-catch in favour of a Result sum type, which is already better than Go's "multiple return that you have to pretend is a sum".
  - potato-peeler 5mo ago
    Which is what should be discussed about go, rather than if-err clauses. That is hardly an issue in go. But Go has these little quirks which, if not careful, can become a problem. But instead most go critiques discuss only the error handling syntax. Look at the other comments. The article is on point on the strengths of go, and in many cases, those other languages you say, you will find it really hard to do the same thing with the ease with which you can do in go. What the article glosses over, is the footguns with working with the language. No compile time nil checks, implicit interfaces, lack of sum types, like you said, which more so often leads to bloated structs, member visibility which is just private and public. You can find more. But these problems were not the main focus of go. Go was build because google devs wanted a simpler way to manage and deploy their software across thousands of services, not having to wait forever for their code to compile, not worrying about writing cpp code in the BEST possible industry standard, ability to do parallel processing of hundreds or thousands of workloads without choking your cpu, managing dependency hell. These were actual roadblocks. And google was not the only one facing these problems. Go solved all of it. Which language was solving this before go?
    - pjmlp 5mo ago
      Go was developed because two UNIX guys, and one Oberon guy, that didn't like C++ decided to create their own thing, and their manager decided to support them as their 20% project. Nothing else. The narrative of Google wanting Go never happened, it gets sold as such by many Googlers. Even Kubernetes was originally written in Java, before some Go folks joined in and drove the rewrite into Go, which besides the Android build system are the only two key projects using Go.
clausecker 5mo ago
> No it really doesn't. It litters your code with if statements that are all just about the same, except that one that needs to be different, and you go blind looking at them all and can't spot the difference. If most of your error handling is just bubbling the error up, you are doing something wrong. if err != nil { return err; } is an antipattern. Not because it's verbose, but because you are supposed to handle the error, not pass it right through, in most cases.

potato-peeler 5mo ago

> No it really doesn't. It litters your code with if statements that are all just about the same Wrong thing to be bothered with. This allows static analysis of every possible path the code can take. Try to do that with throw/catch. There is a reason many industry guidelines like misra, jsf, etc just outright ban hidden paths. They have been literally catastrophic. There is a reason why many modern languages like go, rust, etc, want errors to be explicitly handled. Go documentation specifically reasons why they treat errors-as-values and why is it like that - https://go.dev/doc/faq#exceptions https://go.dev/doc/faq#exceptions > Rust converts the common case boilerplate down into one character: ? which lets you focus on any exceptional error handling rather than a wall of if statements that almost all look alike Again, wrong way to look at errors. Errors are not a problem for a compiler to resolve. Errors are part of your business logic. They need to be explicit and handled. The syntax of one language vs another is not the point of error handling. Errors are not a distraction. It is your job to review each path the code can take. Code may be written once, but code is always reviewed or audited or referenced more than once. No one is impressed if you write some meta magic one-liner. I would rather be more impressed if I can read your code and form a mental image on how many paths your code takes to achieve an outcome in a single sitting, instead of pinging you for a quick call to explain yourself. > you go blind looking at them all and can't spot the difference > And these days people probably just type "tab" and their LLM assistant fills out the entire block incorrectly in one keypress copying the pattern from everything else Now, if someone is 'going blind' looking at error checks, its because their function is doing too much and has too many failure points. Perhaps one may need to focus on honing their software engineering skills on how to structure their code, instead of hitting that 'tab' more so often.

jesseschalken 5mo ago
Go has plenty of hidden code paths in defer, panic and recover. You can minimise the use of those things, just like in other languages you can minimise use of try-catch in favour of a Result sum type, which is already better than Go's "multiple return that you have to pretend is a sum".
- potato-peeler 5mo ago
  Which is what should be discussed about go, rather than if-err clauses. That is hardly an issue in go. But Go has these little quirks which, if not careful, can become a problem. But instead most go critiques discuss only the error handling syntax. Look at the other comments. The article is on point on the strengths of go, and in many cases, those other languages you say, you will find it really hard to do the same thing with the ease with which you can do in go. What the article glosses over, is the footguns with working with the language. No compile time nil checks, implicit interfaces, lack of sum types, like you said, which more so often leads to bloated structs, member visibility which is just private and public. You can find more. But these problems were not the main focus of go. Go was build because google devs wanted a simpler way to manage and deploy their software across thousands of services, not having to wait forever for their code to compile, not worrying about writing cpp code in the BEST possible industry standard, ability to do parallel processing of hundreds or thousands of workloads without choking your cpu, managing dependency hell. These were actual roadblocks. And google was not the only one facing these problems. Go solved all of it. Which language was solving this before go?
  - pjmlp 5mo ago
    Go was developed because two UNIX guys, and one Oberon guy, that didn't like C++ decided to create their own thing, and their manager decided to support them as their 20% project. Nothing else. The narrative of Google wanting Go never happened, it gets sold as such by many Googlers. Even Kubernetes was originally written in Java, before some Go folks joined in and drove the rewrite into Go, which besides the Android build system are the only two key projects using Go.

clausecker 5mo ago

> No it really doesn't. It litters your code with if statements that are all just about the same, except that one that needs to be different, and you go blind looking at them all and can't spot the difference. If most of your error handling is just bubbling the error up, you are doing something wrong. if err != nil { return err; } is an antipattern. Not because it's verbose, but because you are supposed to handle the error, not pass it right through, in most cases.