3 ms·

This really irritated me when I started working with go, but it stopped bothering me and now I even mostly like it. The missing error checks are annoying, but

This really irritated me when I started working with go, but it stopped bothering me and now I even mostly like it. The missing error checks are annoying, but if you have appropriate editor config it is hard to miss them: https://cdn.billmill.org/static/newsyctmp/warning.png https://cdn.billmill.org/static/newsyctmp/warning.png Basically writing go without `staticcheck`[1] is not recommended. If you do have it set up, it's pretty easy to avoid simple errors like that. I do wish the compiler checked it for you. [1]: https://staticcheck.io/ https://staticcheck.io/

masklinn 4y ago
> This really irritated me when I started working with go, but it stopped bothering me and now I even mostly like it. Don’t get me wrong I like a good unused code warning. What frustrates me is that Go’s is dumb / unreliable, and it will stop you from working entirely until you’ve complied with this whim, which has a fraction of a percent chance of identifying a real bug. > Basically writing go without `staticcheck`[1] is not recommended. So why have these things as mandatory compiler errors?
- mirekrusin 4y ago
  So you don't publish it. I guess they could have levels and allow them in debug mode or with special flag or something?
  - pcwalton 4y ago
    -Werror by default would still be mildly annoying, but I'd like it a lot better than what Go and Zig do. At least then I could shell alias "go" to "go -Wno-error".
  - masklinn 4y ago
    > So you don't publish it. Why do they care? > I guess they could have levels and allow them in debug mode or with special flag or something? Well yes, that's how normal compilers do things.
    - mayormcheeseman 4y ago
      I’d assume they care because Go was designed to keep the codebase as “neat” and clean as possible when being worked on by many developers. Given enough time and developers, things like unused variables will start to seep in and make the codebase dirtier. Of course if you’re the only developer working on your own codebase, you’d wonder why they care but you’re also not the main group they were targeting.
      - masklinn 4y ago
        > I’d assume they care because Go was designed to keep the codebase as “neat” and clean as possible when being worked on by many developers So someone’s anal retentive was made into a langage mandate rather than anything actually useful? > Given enough time and developers, things like unused variables will start to seep in and make the codebase dirtier. Why are dead variables any dirtier than dead stores? Or unchecked errors?
        naasking 4y ago
        > Why are dead variables any dirtier than dead stores? If you mean stores to fresh local variables, I assume that should also count in a proper/ideal implementation of this. If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it. In principle, a dead variable in final code is also almost certainly a mistake: either by not including the variable in the computation or for declaring the variable at all. Maybe a little annoying while you're figuring something out, but makes sense in the context of polished code.
        masklinn 4y ago
        > If you mean stores to fresh local variables I mean stores for which there is no load. > I assume that should also count in a proper/ideal implementation of this. It certainly does in a proper implementation, but not in zig. Or go. > If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it. That sounds stupid. > a dead variable in final code is also almost certainly a mistake See “final code” is the issue at hand. The problem with go is that it specifically does not do that. It has a half-assed implementation which it forces upon you all the time. > Maybe a little annoying while you're figuring something out It’s a bloody nuisance when you new figuring things out or in the middle or refactoring something. > but makes sense in the context of polished code. There’s a ton more which makes sense “in the context of polished code” which go can’t be arsed to do. Checking that errors are not implicitly ignored for starters.
thegeekpirate 4y ago
Use golangci-lint (https://golangci-lint.run https://golangci-lint.run, https://github.com/golangci/golangci-lint https://github.com/golangci/golangci-lint) which combines all of the best lints (including staticcheck).

masklinn 4y ago

> This really irritated me when I started working with go, but it stopped bothering me and now I even mostly like it. Don’t get me wrong I like a good unused code warning. What frustrates me is that Go’s is dumb / unreliable, and it will stop you from working entirely until you’ve complied with this whim, which has a fraction of a percent chance of identifying a real bug. > Basically writing go without `staticcheck`[1] is not recommended. So why have these things as mandatory compiler errors?

mirekrusin 4y ago
So you don't publish it. I guess they could have levels and allow them in debug mode or with special flag or something?
- pcwalton 4y ago
  -Werror by default would still be mildly annoying, but I'd like it a lot better than what Go and Zig do. At least then I could shell alias "go" to "go -Wno-error".
- masklinn 4y ago
  > So you don't publish it. Why do they care? > I guess they could have levels and allow them in debug mode or with special flag or something? Well yes, that's how normal compilers do things.
  - mayormcheeseman 4y ago
    I’d assume they care because Go was designed to keep the codebase as “neat” and clean as possible when being worked on by many developers. Given enough time and developers, things like unused variables will start to seep in and make the codebase dirtier. Of course if you’re the only developer working on your own codebase, you’d wonder why they care but you’re also not the main group they were targeting.
    - masklinn 4y ago
      > I’d assume they care because Go was designed to keep the codebase as “neat” and clean as possible when being worked on by many developers So someone’s anal retentive was made into a langage mandate rather than anything actually useful? > Given enough time and developers, things like unused variables will start to seep in and make the codebase dirtier. Why are dead variables any dirtier than dead stores? Or unchecked errors?
      - naasking 4y ago
        > Why are dead variables any dirtier than dead stores? If you mean stores to fresh local variables, I assume that should also count in a proper/ideal implementation of this. If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it. In principle, a dead variable in final code is also almost certainly a mistake: either by not including the variable in the computation or for declaring the variable at all. Maybe a little annoying while you're figuring something out, but makes sense in the context of polished code.
        masklinn 4y ago
        > If you mean stores to fresh local variables I mean stores for which there is no load. > I assume that should also count in a proper/ideal implementation of this. It certainly does in a proper implementation, but not in zig. Or go. > If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it. That sounds stupid. > a dead variable in final code is also almost certainly a mistake See “final code” is the issue at hand. The problem with go is that it specifically does not do that. It has a half-assed implementation which it forces upon you all the time. > Maybe a little annoying while you're figuring something out It’s a bloody nuisance when you new figuring things out or in the middle or refactoring something. > but makes sense in the context of polished code. There’s a ton more which makes sense “in the context of polished code” which go can’t be arsed to do. Checking that errors are not implicitly ignored for starters.

thegeekpirate 4y ago

Use golangci-lint (https://golangci-lint.run https://golangci-lint.run, https://github.com/golangci/golangci-lint https://github.com/golangci/golangci-lint) which combines all of the best lints (including staticcheck).