5 ms·

The go compiler is surprisingly easy to modify! I made a modification that allows it to issue warnings instead of errors for unused imports, variables, etc [1].

The go compiler is surprisingly easy to modify! I made a modification that allows it to issue warnings instead of errors for unused imports, variables, etc [1]. It was a fun little exercise :) [1] https://github.com/kstenerud/go https://github.com/kstenerud/go

mavelikara 7y ago
This is the commit in question: https://github.com/kstenerud/go/commit/334e03f12c9c94fe6adedfcbac105a4c9c19aba3 https://github.com/kstenerud/go/commit/334e03f12c9c94fe6aded.... Cool mod!
saagarjha 7y ago
Now if only this got merged into mailine ;)
- dullgiulio 7y ago
  Why? The idea that warnings are errors is pretty important actually. Now, unused imports are mostly harmless (alright, they are not because of init), but they keep unrelated commits clean without needing ad-hoc linting or IDE functionality.
  - kstenerud 7y ago
    It's explained in the use case: https://github.com/kstenerud/go#use-case https://github.com/kstenerud/go#use-case Use Case The use case for warnings is the exploratory development or debugging phases, where you really don't care about leaving unused things lying around for the time being (for example, temporarily commenting something out), and would rather that the compiler just got out of your way until you've got something ready to compile normally and commit. Usage go build -gcflags=-warnunused somefile.go go test -gcflags=-warnunused When you're done with your exploratory/debugging phase, simply build or test without the flag: go build somefile.go go test Compiling without the flags will fail on unused things as normal.
    - amiller2571 7y ago
      "I really need to get this deployed to production. I'll remove the warning debugging flag and build it... AH MAN look at all these unused import error!! Screw it! I don't have time to fix them all. I'll just add it bad and fix it later"
      - kstenerud 7y ago
        When your devs do these kinds of things, the problem isn't the tools. I like tools that serve me, not the other way around.
        eternalban 7y ago
        That is a valid position, but imo at odds with the implicit position of Go's creators. Arguably, the Mommy regime of Go's compiler is very much reflective of Go's creators' appraisal of the software maturity of its intended users. Regarding the point in general, the notion of "broken windows" is applicable. (Great github showcase, btw!)
        kstenerud 7y ago
        It's the problem of "he knows what he's doing" vs "I know what I'm doing". In the old unix days, tools were built under the assumption that "he knows what he's doing", meaning that if you typed "rm -r /" you probably had a good reason to do so. We've since learned that just blindly trusting potentially fat fingers is probably not the best approach, and so the more dangerous of those tools have been modified to require you to add additional flags to do the most dangerous things. It was the same in C, where the compiler blindly did exactly as told until we realized that software developers have fat fingers too. Unfortunately, they got it backwards, issuing warnings that by default don't halt compilation ("he knows what he's doing"), which led users and managers to believe that warnings aren't serious enough to deal with. What they SHOULD have done is made those warnings halt compilation by default, and only allow compilation to continue if the user had invoked an additional opt-in ("I know what I'm doing") flag. There's also the issue of inconsistent warnings across compilers and the subtleties of UB in C that contributed to the warnings problem, but we don't have that in Go.
- tptacek 7y ago
  I used to want that too, but I've paid pretty close attention over the last couple years and that error has caught a nonzero number of what would otherwise have been runtime bugs.
  - napsterbr 7y ago
    For production I agree 100% with you, to the point I think it's just sloppy to leave unused variables and imports hanging around. But during development that's just a needless obstacle. I may comment large blocks of code and I don't want to scan each import to make sure they are no longer used.
    - tptacek 7y ago
      I assume at this point that at least a plurality of Go developers are using goimports and having this stuff handled automatically. That's probably another reason my opinion on this shifted.
      - kstenerud 7y ago
        If IDEs did the same for unused variables, I'd probably shift as well, but right now, commenting out a line quickly degenerates into a game of whack a mole, because it causes a previous calculation to become "unused", and commenting out that line causes two more things to become unused, etc. The last thing I want during debugging is to have to fight the compiler at every step. Debugging is the main reason I wrote this mod.

mavelikara 7y ago

This is the commit in question: https://github.com/kstenerud/go/commit/334e03f12c9c94fe6adedfcbac105a4c9c19aba3 https://github.com/kstenerud/go/commit/334e03f12c9c94fe6aded.... Cool mod!

saagarjha 7y ago

Now if only this got merged into mailine ;)

dullgiulio 7y ago
Why? The idea that warnings are errors is pretty important actually. Now, unused imports are mostly harmless (alright, they are not because of init), but they keep unrelated commits clean without needing ad-hoc linting or IDE functionality.
- kstenerud 7y ago
  It's explained in the use case: https://github.com/kstenerud/go#use-case https://github.com/kstenerud/go#use-case Use Case The use case for warnings is the exploratory development or debugging phases, where you really don't care about leaving unused things lying around for the time being (for example, temporarily commenting something out), and would rather that the compiler just got out of your way until you've got something ready to compile normally and commit. Usage go build -gcflags=-warnunused somefile.go go test -gcflags=-warnunused When you're done with your exploratory/debugging phase, simply build or test without the flag: go build somefile.go go test Compiling without the flags will fail on unused things as normal.
  - amiller2571 7y ago
    "I really need to get this deployed to production. I'll remove the warning debugging flag and build it... AH MAN look at all these unused import error!! Screw it! I don't have time to fix them all. I'll just add it bad and fix it later"
    - kstenerud 7y ago
      When your devs do these kinds of things, the problem isn't the tools. I like tools that serve me, not the other way around.
      - eternalban 7y ago
        That is a valid position, but imo at odds with the implicit position of Go's creators. Arguably, the Mommy regime of Go's compiler is very much reflective of Go's creators' appraisal of the software maturity of its intended users. Regarding the point in general, the notion of "broken windows" is applicable. (Great github showcase, btw!)
        kstenerud 7y ago
        It's the problem of "he knows what he's doing" vs "I know what I'm doing". In the old unix days, tools were built under the assumption that "he knows what he's doing", meaning that if you typed "rm -r /" you probably had a good reason to do so. We've since learned that just blindly trusting potentially fat fingers is probably not the best approach, and so the more dangerous of those tools have been modified to require you to add additional flags to do the most dangerous things. It was the same in C, where the compiler blindly did exactly as told until we realized that software developers have fat fingers too. Unfortunately, they got it backwards, issuing warnings that by default don't halt compilation ("he knows what he's doing"), which led users and managers to believe that warnings aren't serious enough to deal with. What they SHOULD have done is made those warnings halt compilation by default, and only allow compilation to continue if the user had invoked an additional opt-in ("I know what I'm doing") flag. There's also the issue of inconsistent warnings across compilers and the subtleties of UB in C that contributed to the warnings problem, but we don't have that in Go.
tptacek 7y ago
I used to want that too, but I've paid pretty close attention over the last couple years and that error has caught a nonzero number of what would otherwise have been runtime bugs.
- napsterbr 7y ago
  For production I agree 100% with you, to the point I think it's just sloppy to leave unused variables and imports hanging around. But during development that's just a needless obstacle. I may comment large blocks of code and I don't want to scan each import to make sure they are no longer used.
  - tptacek 7y ago
    I assume at this point that at least a plurality of Go developers are using goimports and having this stuff handled automatically. That's probably another reason my opinion on this shifted.
    - kstenerud 7y ago
      If IDEs did the same for unused variables, I'd probably shift as well, but right now, commenting out a line quickly degenerates into a game of whack a mole, because it causes a previous calculation to become "unused", and commenting out that line causes two more things to become unused, etc. The last thing I want during debugging is to have to fight the compiler at every step. Debugging is the main reason I wrote this mod.