6 ms·

God I get tired of the if err criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over

God I get tired of the if err criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it.

satvikpendem 4y ago
Your profile link doesn't work. Regarding `if err`, it's one thing to add it everywhere, it's another to forget and then have something break. If Go also checked for exhaustive error handling, I wouldn't mind it either.
- Zagill 4y ago
  This is pretty trivial to accomplish with linters. Where I work your build will fail if you have unchecked err's hanging around, along with a lot of other sorts of issues. No, it's not built into the language by default or anything, but is that dealbreaking?
  - satvikpendem 4y ago
    It is dealbreaking. These days I gravitate more and more towards strongly statically typed languages over weakly dynamically typed ones, which I definitely used to use when younger. Fact is, linters are simply not the same as something built-in from the ground up. Trust me, I have written many thousands of lines of Python and Ruby, and even with linters, they don't hold a candle to even something like TypeScript in terms of type ergonomics and refactorability, not to mention even stronger languages like Haskell or OCaml. Anecdotally this is the same argument many C++ devs make in regards to Rust safety guarantees. The difference is just...different.
    - pipe_connector 4y ago
      In general I agree with you, but Go's simple syntax means that there are extremely few (if any? I've never run into one) edge cases with checking that an error was at least considered. The guarantees are the same as what you get with e.g. Rust. The only difference is that you have to run a third party's code, which I don't like, either.
      - satvikpendem 4y ago
        > The guarantees are the same as what you get with e.g. Rust. I'm not sure how they could be, given that Rust checks exhaustively and Go doesn't. If one programmer messes up, then that's it, an unhandled exception might occur in the future. I would rather rely on the computer telling me when it should be handled over humans.
        kika 4y ago
        And the worst human to tell you that is an SRE
    - Zagill 4y ago
      Well for one, Go is not a weakly, dynamically typed language, and this also isn't an issue of type checking at all.
      - satvikpendem 4y ago
        Sure, I did not mean Go specifically when I said that, just stating how when I used linters in other such languages, it was not comprehensive enough to replace a language with types and other niceties built-in. I also don't use much Go because it lacks good algebraic data type support, honestly can't imagine going back to a language that doesn't have them as I like to define all my business logic in types and then build the actual application from there. Go simply doesn't have that capability.
        Zagill 4y ago
        I'm not familiar with algebraic data types, what's missing from Go that makes that impossible? Sounds about like defining structs/other custom types before writing any method bodies, which is what I'd typically do in a Go project.
        satvikpendem 4y ago
        > what's missing from Go that makes that impossible? The language maintainers don't want to add it: https://github.com/golang/go/issues/19412 https://github.com/golang/go/issues/19412
- pipe_connector 4y ago
  https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck Every Go project I've worked on has used this linter. I think it should be builtin, but it's very easy to incorporate.
  - shepherdjerred 4y ago
    > but it's very easy to incorporate. As someone who is adding this to a Go project with hundreds of unchecked errors, I disagree.
  - styluss 4y ago
    What kind of error does it check?
    - panachaud 4y ago
      It looks for code where the err != nil hasn’t been handled
deleted 4y ago
[deleted]
deagle50 4y ago
It's super annoying, I switched from Go to Rust for my personal projects because of it. It's like a seat belt beep that won't stop.
thayne 4y ago
That just means you have written a lot of go. I truthfully don't notice lifetimes or the borrow checker most of the time when I write rust. I actually think that, ironically, the if err problem with go is worse for reading code than writing code. If you are used to the pattern it's not that difficult to add the `if err != nil` after a fallible function call, and as is mentioned elsewhere, linters can help catch if you miss it. However, if you are trying to figure out what a function is doing, it can be very difficult to follow the flow, when 3/4 of the code is if err != null { return err } especially if you don't have a lot of experience reading go code. And that 3/4 is not an exaggeration. I have had to read functions where literally every line of normal logic is followed by those three lines to propagate the error from the other function. A function that would otherwise fit on a single screen now takes up over three screens worth of scrolling.
- derangedHorse 4y ago
  I don't see how that's a specific problem of the Go programming language though. Rust still has option types and the cases where an Option could be None still need to be handled. Maybe the big difference is the compiler forcing the handling of this case but it seems like a small thing for experienced programmers. Rust's default paradigm for memory management seems more significant of a language feature in my opinion and is what I can imagine most people don't like. A lot of the programs I write don't fall into the class of problems Rust is trying to prevent which makes the restrictions it enforces bothersome for me.
  - thayne 4y ago
    > Rust still has option types and the cases where an Option could be None still need to be handled And rust has the `?` operator, as well as combinators like `map`, `and_then`, `unwrap_or_else`, etc. which IMO make the flow much easier to follow than say `if option.is_none() { return None }`. > Rust's default paradigm for memory management seems more significant of a language feature in my opinion and is what I can imagine most people don't like I never said it wasn't. My point is that if you use a language enough you get used to things that are difficult for people less experienced with that language.
deleted 4y ago
[deleted]
Aeolun 4y ago
I dunno, if my exceptions would have to be manually rethrown every time, I’d get really cranky very quickly. I don’t think that’s any better in Rust though.
- ColonelPhantom 4y ago
  Rust has many convenient shorthands like the ? operator, where `let x = foo()?` is equivalent to let x = match foo() { Ok(value) -> value, Err(e) -> return Err(e), }
  - cesarb 4y ago
    IIRC, `let x = foo()?` is actually equivalent to let x = match foo() { Ok(value) -> value, Err(e) -> return Err(e.into()), } Which can automatically convert one error type into another when the appropriate From and/or Into impls exist.
    - steveklabnik 4y ago
      It is a little more complex than that these days https://github.com/rust-lang/rust/blob/4e0d0d757e2f1b61ec809420b006545a9f8974c0/compiler/rustc_ast_lowering/src/expr.rs#L1565-L1576 https://github.com/rust-lang/rust/blob/4e0d0d757e2f1b61ec809...
  - rob74 4y ago
    Many convenient shorthands that you all have to be familiar with before being able to write (and read) Rust competently. I guess that's what they mean with the steep learning curve...
bpicolo 4y ago
If anything, context param drilling due to lack of thread local variable or similar is way less ergonomic
caladin 4y ago
This reminds me of the same response regarding generics from Go users: > God I get tired of the generics criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it. Over ten years later, Go gets generics.
- foldr 4y ago
  There’s no contradiction there. I rarely missed generics in Go. Now on the rare occasion that they add significant value, I can use them.
lenkite 4y ago
It's hard catching bugs in go when your eyes tend to glaze over tens of thousands of 'if err != nil' statements causing bad signal-to-noise ratio. I actually like Go over Rust, but really, really wish the language provided some more ergonomics and fixed several of its terrible gotchas. (the for loop issue for example) Also wish Go gets RAII some day.

God I get tired of the if err criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it.

satvikpendem 4y ago

Your profile link doesn't work. Regarding `if err`, it's one thing to add it everywhere, it's another to forget and then have something break. If Go also checked for exhaustive error handling, I wouldn't mind it either.

Zagill 4y ago
This is pretty trivial to accomplish with linters. Where I work your build will fail if you have unchecked err's hanging around, along with a lot of other sorts of issues. No, it's not built into the language by default or anything, but is that dealbreaking?
- satvikpendem 4y ago
  It is dealbreaking. These days I gravitate more and more towards strongly statically typed languages over weakly dynamically typed ones, which I definitely used to use when younger. Fact is, linters are simply not the same as something built-in from the ground up. Trust me, I have written many thousands of lines of Python and Ruby, and even with linters, they don't hold a candle to even something like TypeScript in terms of type ergonomics and refactorability, not to mention even stronger languages like Haskell or OCaml. Anecdotally this is the same argument many C++ devs make in regards to Rust safety guarantees. The difference is just...different.
  - pipe_connector 4y ago
    In general I agree with you, but Go's simple syntax means that there are extremely few (if any? I've never run into one) edge cases with checking that an error was at least considered. The guarantees are the same as what you get with e.g. Rust. The only difference is that you have to run a third party's code, which I don't like, either.
    - satvikpendem 4y ago
      > The guarantees are the same as what you get with e.g. Rust. I'm not sure how they could be, given that Rust checks exhaustively and Go doesn't. If one programmer messes up, then that's it, an unhandled exception might occur in the future. I would rather rely on the computer telling me when it should be handled over humans.
      - kika 4y ago
        And the worst human to tell you that is an SRE
  - Zagill 4y ago
    Well for one, Go is not a weakly, dynamically typed language, and this also isn't an issue of type checking at all.
    - satvikpendem 4y ago
      Sure, I did not mean Go specifically when I said that, just stating how when I used linters in other such languages, it was not comprehensive enough to replace a language with types and other niceties built-in. I also don't use much Go because it lacks good algebraic data type support, honestly can't imagine going back to a language that doesn't have them as I like to define all my business logic in types and then build the actual application from there. Go simply doesn't have that capability.
      - Zagill 4y ago
        I'm not familiar with algebraic data types, what's missing from Go that makes that impossible? Sounds about like defining structs/other custom types before writing any method bodies, which is what I'd typically do in a Go project.
        satvikpendem 4y ago
        > what's missing from Go that makes that impossible? The language maintainers don't want to add it: https://github.com/golang/go/issues/19412 https://github.com/golang/go/issues/19412
pipe_connector 4y ago
https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck Every Go project I've worked on has used this linter. I think it should be builtin, but it's very easy to incorporate.
- shepherdjerred 4y ago
  > but it's very easy to incorporate. As someone who is adding this to a Go project with hundreds of unchecked errors, I disagree.
- styluss 4y ago
  What kind of error does it check?
  - panachaud 4y ago
    It looks for code where the err != nil hasn’t been handled

deleted 4y ago

[deleted]

deagle50 4y ago

It's super annoying, I switched from Go to Rust for my personal projects because of it. It's like a seat belt beep that won't stop.

thayne 4y ago

That just means you have written a lot of go. I truthfully don't notice lifetimes or the borrow checker most of the time when I write rust. I actually think that, ironically, the if err problem with go is worse for reading code than writing code. If you are used to the pattern it's not that difficult to add the `if err != nil` after a fallible function call, and as is mentioned elsewhere, linters can help catch if you miss it. However, if you are trying to figure out what a function is doing, it can be very difficult to follow the flow, when 3/4 of the code is if err != null { return err } especially if you don't have a lot of experience reading go code. And that 3/4 is not an exaggeration. I have had to read functions where literally every line of normal logic is followed by those three lines to propagate the error from the other function. A function that would otherwise fit on a single screen now takes up over three screens worth of scrolling.

derangedHorse 4y ago
I don't see how that's a specific problem of the Go programming language though. Rust still has option types and the cases where an Option could be None still need to be handled. Maybe the big difference is the compiler forcing the handling of this case but it seems like a small thing for experienced programmers. Rust's default paradigm for memory management seems more significant of a language feature in my opinion and is what I can imagine most people don't like. A lot of the programs I write don't fall into the class of problems Rust is trying to prevent which makes the restrictions it enforces bothersome for me.
- thayne 4y ago
  > Rust still has option types and the cases where an Option could be None still need to be handled And rust has the `?` operator, as well as combinators like `map`, `and_then`, `unwrap_or_else`, etc. which IMO make the flow much easier to follow than say `if option.is_none() { return None }`. > Rust's default paradigm for memory management seems more significant of a language feature in my opinion and is what I can imagine most people don't like I never said it wasn't. My point is that if you use a language enough you get used to things that are difficult for people less experienced with that language.

deleted 4y ago

[deleted]

Aeolun 4y ago

I dunno, if my exceptions would have to be manually rethrown every time, I’d get really cranky very quickly. I don’t think that’s any better in Rust though.

ColonelPhantom 4y ago
Rust has many convenient shorthands like the ? operator, where `let x = foo()?` is equivalent to let x = match foo() { Ok(value) -> value, Err(e) -> return Err(e), }
- cesarb 4y ago
  IIRC, `let x = foo()?` is actually equivalent to let x = match foo() { Ok(value) -> value, Err(e) -> return Err(e.into()), } Which can automatically convert one error type into another when the appropriate From and/or Into impls exist.
  - steveklabnik 4y ago
    It is a little more complex than that these days https://github.com/rust-lang/rust/blob/4e0d0d757e2f1b61ec809420b006545a9f8974c0/compiler/rustc_ast_lowering/src/expr.rs#L1565-L1576 https://github.com/rust-lang/rust/blob/4e0d0d757e2f1b61ec809...
- rob74 4y ago
  Many convenient shorthands that you all have to be familiar with before being able to write (and read) Rust competently. I guess that's what they mean with the steep learning curve...

bpicolo 4y ago

If anything, context param drilling due to lack of thread local variable or similar is way less ergonomic

caladin 4y ago

This reminds me of the same response regarding generics from Go users: > God I get tired of the generics criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it. Over ten years later, Go gets generics.

foldr 4y ago
There’s no contradiction there. I rarely missed generics in Go. Now on the rare occasion that they add significant value, I can use them.

lenkite 4y ago

It's hard catching bugs in go when your eyes tend to glaze over tens of thousands of 'if err != nil' statements causing bad signal-to-noise ratio. I actually like Go over Rust, but really, really wish the language provided some more ergonomics and fixed several of its terrible gotchas. (the for loop issue for example) Also wish Go gets RAII some day.