6 ms·

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

by 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

by Zagill 4y ago

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