3 ms·

I would burn Go with fire and salt the earth because it's the bloody compiler will refuse to compile my valid code if I have unused imports or variables. It mak

I would burn Go with fire and salt the earth because it's the bloody compiler will refuse to compile my valid code if I have unused imports or variables. It makes programming in Go a terrible experience and that's why I won't touch it.

Jabbles 11y ago
You'll love goimports then. https://godoc.org/golang.org/x/tools/cmd/goimports https://godoc.org/golang.org/x/tools/cmd/goimports Hook it to your editor's save command and never worry about imports again. On the other hand, stop leaving unused variables around...
- artursapek 11y ago
  I hate debugging someone else's code that has unused variables in it as much as this guy seems to hate the go compiler.
  - GreaterFool 11y ago
    Any normal compiler usually allows overriding these options. I normally write Haskell and it has it all: unused variables, unused imports, name shadowing, non-exhaustive pattern matching, everything. But these things are warnings in my dev build and errors in the release build. That's a sane way to do it.
    - Jabbles 11y ago
      Except some people wouldn't enable -Werror, and the quality of Go code would suffer on average. Plus, now your compiler has options.
      - artursapek 11y ago
        Yeah. I'm a fan of mandates when it comes to things like compiler options. Everyone should just suck it up and work with the same constraints. Warnings are just errors without balls.
- callumlocke 11y ago
  > On the other hand, stop leaving unused variables around... I don't think there's any problem with doing that. I use a linter to stop me committing code that has unused variables in it, and to highlight those kinds of style issues in my editor so I'm aware of them. But for a compiler to refuse to run unpolished code in development is just bad design. It's as if Go's designers took the hubristic or naive view that all code would, in an ideal world, be typed out perfectly first time, as opposed to being gradually hammered into shape through trial and error. This is worse than a design flaw, it feels like an active imposition.
castratikron 11y ago
I think that behavior is annoying, too. I've wonder if there's a way to tell the compiler to generate a warning for unused variables instead of just erroring out.
- GreaterFool 11y ago
  No there isn't. Because Go loves to show you the middle finger.
  - castratikron 11y ago
    Thank you for your constructive comment and downvote
stunthamsterio 11y ago
This to me is one of it's benefits - uncommented, unused variables shouldn't be in code, and I like that the compiler is actively preventing me from being lazy and creating cruft that's simple to remove.

Jabbles 11y ago

You'll love goimports then. https://godoc.org/golang.org/x/tools/cmd/goimports https://godoc.org/golang.org/x/tools/cmd/goimports Hook it to your editor's save command and never worry about imports again. On the other hand, stop leaving unused variables around...

artursapek 11y ago
I hate debugging someone else's code that has unused variables in it as much as this guy seems to hate the go compiler.
- GreaterFool 11y ago
  Any normal compiler usually allows overriding these options. I normally write Haskell and it has it all: unused variables, unused imports, name shadowing, non-exhaustive pattern matching, everything. But these things are warnings in my dev build and errors in the release build. That's a sane way to do it.
  - Jabbles 11y ago
    Except some people wouldn't enable -Werror, and the quality of Go code would suffer on average. Plus, now your compiler has options.
    - artursapek 11y ago
      Yeah. I'm a fan of mandates when it comes to things like compiler options. Everyone should just suck it up and work with the same constraints. Warnings are just errors without balls.
callumlocke 11y ago
> On the other hand, stop leaving unused variables around... I don't think there's any problem with doing that. I use a linter to stop me committing code that has unused variables in it, and to highlight those kinds of style issues in my editor so I'm aware of them. But for a compiler to refuse to run unpolished code in development is just bad design. It's as if Go's designers took the hubristic or naive view that all code would, in an ideal world, be typed out perfectly first time, as opposed to being gradually hammered into shape through trial and error. This is worse than a design flaw, it feels like an active imposition.

castratikron 11y ago

I think that behavior is annoying, too. I've wonder if there's a way to tell the compiler to generate a warning for unused variables instead of just erroring out.

GreaterFool 11y ago
No there isn't. Because Go loves to show you the middle finger.
- castratikron 11y ago
  Thank you for your constructive comment and downvote

stunthamsterio 11y ago

This to me is one of it's benefits - uncommented, unused variables shouldn't be in code, and I like that the compiler is actively preventing me from being lazy and creating cruft that's simple to remove.