4 ms·

I'd categorize not being able to convert "unused thing" errors into warnings during development iterations as one of "The Bad". Just today I had a couple block

by j1elo 3y ago

I'd categorize not being able to convert "unused thing" errors into warnings during development iterations as one of "The Bad". Just today I had a couple blocks of code which were causing erratic issues. Wanted to see if it was the second one, so I quickly commented it out. This is just an exploratory development session, no need to comply with code quality guidelines. Still, the code failed to compile because now I had to worry about 8 lines with stuff that had become unused. The stubbornness about not adding an escape hatch for, again, exploratory intermediate development iterations is unnerving. "But code should not leave unused stuff around". I agree. That's why after a hundred iterations, in the final compilation phase for production, this kind of errors-are-warnings flag would be disabled.

pravus 3y ago
I use a technique I call "runtime comments": if false { ... stuff I don't want to run right now but the compiler still has to deal with it ... }
- j1elo 3y ago
  Well, for that specific case (it was a well defined block that could be all selected and commented out in order to disable it), your technique would have worked fine, true :) But of course it can get tiring and not be very practical if the logic to disable is a little bit more spread out (I'd say having to "if false" anything more than 2 paragraphs or blocks of code would already start to feel annoying)
irq-1 3y ago
This is just an intractable problem: if there is any way for people to leave unused code, they will. If you want the code to be clean, you cannot have (for example) a debug mode that allows unused code, because the code will just be left in 'debug' format. Eventually the community shared code will have so much debug-but-it-works code that you'll never get a system of clean code. And think of what the current strict rule has done: go is the only(?!) language that has a consistently clean ecosystem. When's the last time you looked at go code that huge chunks commented out? That said... it is annoying. More annoying the less import the script, and the faster you want to test something.
- kaba0 3y ago
  Make debug mode have runtime costs automatically (like race checks, less optimizations for faster compile). That way people are left alone while developing (plus getting cool tools for that as well), while are incentivized to build final prod builds for sane performance, for which they have to clean up after themselves. Though personally, I dislike this paternalistic approach to handling devs.
SiVal 3y ago
I completely agree. The wonderful speed of the compiler allows for quick small-change, test, small-change, test development. In theory. They then sabotage it by making "unused" warnings into errors, which forces you to waste the time the fast compiler could have saved, making temporary changes (ex: commenting out/in) that aren't needed for the test and won't be needed for production.
SCLeo 3y ago
Honestly, I'm incredibly frustrated with this issue; it's just pure idiocy. Commenting out a part of the code and observing the effects is such a simple and useful debugging technique, yet this "feature" of Go prevents you from doing so effectively. What's even more frustrating is that when you search for solutions, you come across two kinds of (pardon my language) completely brain-dead responses: First, there are those who argue that unused variables/imports lead to bugs and worse performance in production, so they should always be fixed. But that's completely beside the point; I've never seen anyone argue that allowing unused variables is good for production. It's always been about facilitating the development process and debugging. Yes, I am aware now there are unused variables, but please just let me see what does removing this part of the code do. Secondly, people suggest using a dummy function like UNUSED or a blank variable _ to solve the problem. But again, these suggestions miss the mark entirely. Changing variable names or adding UNUSED calls to "disable" the rule is even worse than what we've been doing to temporarily "circumvent" the rule, which is simply commenting out the declarations, test, and undo afterwards. Not only it involves more effort, but more crucially, you might actually forgot to revert those changes and leave in unused variables. Frankly, I believe this is just a bad design decision, and it seems like the Go team is stubbornly doubling down on this mistake due to ego. (Sorry, I just have a very strong opinion on this topic, and I am deeply frustrated when the tools I am using think they know better than I do and are adamantly wrong.)
- Mawr 3y ago
  > I've never seen anyone argue that allowing unused variables is good for production. It's always been about facilitating the development process and debugging. Yes, I am aware now there are unused variables, but please just let me see what does removing this part of the code do. Yes, but once you allow that, you'll inevitably end up with unused variables in production code (warnings are useless). That's the core of the issue and why the Go team made the decision. In my opinion, the real solution is to have two build modes: --devel and --release. This would allow for not bothering devs with anal checks during development while preventing substandard code in production. Though the real advantage would come from the reduced pressure on compilation speed in --release mode which would make room for more optimization passes, resulting in faster production runtime speed and lower binary size.

by j1elo 3y ago

pravus 3y ago

I use a technique I call "runtime comments": if false { ... stuff I don't want to run right now but the compiler still has to deal with it ... }

j1elo 3y ago
Well, for that specific case (it was a well defined block that could be all selected and commented out in order to disable it), your technique would have worked fine, true :) But of course it can get tiring and not be very practical if the logic to disable is a little bit more spread out (I'd say having to "if false" anything more than 2 paragraphs or blocks of code would already start to feel annoying)

irq-1 3y ago

This is just an intractable problem: if there is any way for people to leave unused code, they will. If you want the code to be clean, you cannot have (for example) a debug mode that allows unused code, because the code will just be left in 'debug' format. Eventually the community shared code will have so much debug-but-it-works code that you'll never get a system of clean code. And think of what the current strict rule has done: go is the only(?!) language that has a consistently clean ecosystem. When's the last time you looked at go code that huge chunks commented out? That said... it is annoying. More annoying the less import the script, and the faster you want to test something.

kaba0 3y ago
Make debug mode have runtime costs automatically (like race checks, less optimizations for faster compile). That way people are left alone while developing (plus getting cool tools for that as well), while are incentivized to build final prod builds for sane performance, for which they have to clean up after themselves. Though personally, I dislike this paternalistic approach to handling devs.

SiVal 3y ago

I completely agree. The wonderful speed of the compiler allows for quick small-change, test, small-change, test development. In theory. They then sabotage it by making "unused" warnings into errors, which forces you to waste the time the fast compiler could have saved, making temporary changes (ex: commenting out/in) that aren't needed for the test and won't be needed for production.

SCLeo 3y ago

Honestly, I'm incredibly frustrated with this issue; it's just pure idiocy. Commenting out a part of the code and observing the effects is such a simple and useful debugging technique, yet this "feature" of Go prevents you from doing so effectively. What's even more frustrating is that when you search for solutions, you come across two kinds of (pardon my language) completely brain-dead responses: First, there are those who argue that unused variables/imports lead to bugs and worse performance in production, so they should always be fixed. But that's completely beside the point; I've never seen anyone argue that allowing unused variables is good for production. It's always been about facilitating the development process and debugging. Yes, I am aware now there are unused variables, but please just let me see what does removing this part of the code do. Secondly, people suggest using a dummy function like UNUSED or a blank variable _ to solve the problem. But again, these suggestions miss the mark entirely. Changing variable names or adding UNUSED calls to "disable" the rule is even worse than what we've been doing to temporarily "circumvent" the rule, which is simply commenting out the declarations, test, and undo afterwards. Not only it involves more effort, but more crucially, you might actually forgot to revert those changes and leave in unused variables. Frankly, I believe this is just a bad design decision, and it seems like the Go team is stubbornly doubling down on this mistake due to ego. (Sorry, I just have a very strong opinion on this topic, and I am deeply frustrated when the tools I am using think they know better than I do and are adamantly wrong.)

Mawr 3y ago
> I've never seen anyone argue that allowing unused variables is good for production. It's always been about facilitating the development process and debugging. Yes, I am aware now there are unused variables, but please just let me see what does removing this part of the code do. Yes, but once you allow that, you'll inevitably end up with unused variables in production code (warnings are useless). That's the core of the issue and why the Go team made the decision. In my opinion, the real solution is to have two build modes: --devel and --release. This would allow for not bothering devs with anal checks during development while preventing substandard code in production. Though the real advantage would come from the reduced pressure on compilation speed in --release mode which would make room for more optimization passes, resulting in faster production runtime speed and lower binary size.