It's pretty hilarious to watch people clambering all over each other in this thread to claim this isn't a problem because [op_is_doing_it_wrong] or [weird_hacky_workaround]. Commenting out bits of code to see what effects it has is one of the most useful ways of not only debugging a program, but learning to program, and “reading” code.<p>Just because some really smart people made a decision for reasons that are great 99% of the time, but fail badly in a very important 1% case doesn't mean you have to redefine your entire belief system to avoid criticizing them.
One solution to the fmt.Println problem is not to use it at all. There's a built in println function that works alright for debugging messages and requires no import.<p><a href="http://play.golang.org/p/y5XX4RDTW5" rel="nofollow">http://play.golang.org/p/y5XX4RDTW5</a>
> if something is worth warning about it's worth making it an error<p>Why oh why do people think this way, totally conflating things?! It makes any "explorative programming" extremely painful. Really, can't I indulge in a sloppy coding style while prototyping something, have a zillion warnings pop up (or silence them with a compiler flag), have a working prototype with ugly hacks and worst practices and then move on to slowly fix the things till I get a 0 warning 0 errors "clean state".<p>Not all have the god-programmer mind to start with a "good design". We grow things organically, function by function, class by class. We start from a "ball of mud" and slowly mold it into the shape of our desire (now I agree that for the different style of programming that starts from a "good design" and works hard to prevent everything from turning into a ball of mud, having straight jackets" is good, but if I don't want to live in your "cathedral asylum", then don't force me to wear one!). Every line of code is and will be rewritten time and time again. <i>And you need warnings and errors to be very different concepts to do this style of programming!</i>
This is hardly surprising considering Go shares its creators with Plan 9 among other things. They have had this kind of attitude for years, see for example this thread where someone asks about some features in the Acme editor:<p><a href="http://9fans.net/archive/2008/08/134" rel="nofollow">http://9fans.net/archive/2008/08/134</a><p>"Just say no"
When debugging, add the package-level statement var _ = fmt.Println to avoid unused errors. Here's an example: <a href="http://play.golang.org/p/cZtmILYWoZ" rel="nofollow">http://play.golang.org/p/cZtmILYWoZ</a>
> <i>I'm all for opinionated language design, but when you use your compiler to cudgel your coders at the cost of productivity, you lose.</i><p>Well, the thing is that in the long run, the cost of any software system is dominated by fixing bugs with high degree of latency. Removing various classes of error by compiler fiat is an approach that is wildly unpopular but well studied.<p>This sentence might have been written as:<p>> <i>I'm all for opinionated language design, so long as I agree with the opinion.</i><p>And that's fine. I can only speak for myself when I say that while younger me was annoyed that the damn compiler won't get out of the way, older me is annoyed that the damn compiler didn't catch this obvious defect for me.<p>The difference is that older me is writing less trivial programs and dealing with more existing code and writing more complicated systems.
Can't you just write a debug function, that checks a variable, then either does nothing or calls fmt.Println? Set the variable from a command line parameter. Sprinkle debug statements everywhere you want, and flip the parameter as needed.<p>Since the import is always used, it is never an error. No problem.
Yesterday I was complaining a bit about Go, so let me partially balance the scales by observing that in terms of examining this for use at my work, I <i>absolutely love</i> this and consider it a major plus point. Dealing with "fmt" is annoying, yes, and I sort of wish I could exclude that module from the rules. But I currently live with a huge code base in Perl, which is as far away from Go on this matter as it is possible to get, and after years of cruft buildup, it's virtually impossible to ever remove any imports from a module. You just can't tell what will happen, ever. Removing a "use X" from module Y may in fact break very-distant module Z because it happened to directly invoke X::function without ever having loaded X itself, it was accidentally depending on X being loaded by Y. Yeah, that one's easy enough to find and diagnose, but these get arbitrarily subtle.
Aside from the var _ = fmt.Println trick to avoid having to comment out the module import, maybe part of the problem is that Go is aimed a little further think-ahead-ward and a little less hack-until-it-works-ward than they're used to? Because that might be on purpose.
The OP offers up Python as an example of "weightlessness", which I take as meaning "it will execute any code it can parse." Languages with this kind of tolerance require exhausting levels of diligence to verify assumptions and ensure consistency in a development team.<p>Go's pedantic compiler and style enforcement fade pretty quickly into the background with practice and a reasonable text editor. The pain of trying to fix mixed metaphors between modules in Python never will.<p>As an aside, here is the solution to your fmt.Println problem:<p><pre><code> func traceln(v ... interface{}) {
fmt.Println(v...)
}
</code></pre>
Just bind the function, and you can comment or uncomment traceln to your heart's desire.
I have had this problem as well and of course you can add some superfluous code that fulfills the usage for the import/variable but then you have to remember to clean up that code later (essentially discarding the very helpful checking built into the compiler).<p>I think they would be better off adding a compiler flag for less strict checking for development.
This is the kind of problem that can and arguably should be handled/eased by whatever editor or IDE you are using. A quick key combination to clear unused imports, another one to add required imports.
One thing I always thought would be interesting to do is make it such that the "enforced stylistic" bits of a language were tied to the optimization settings. For example, make warnings not halt the compile on the compiler's equivalent for -O0, and then on any higher optimization setting, they become compiler errors that can't be turned off. It doesn't completely prevent people from doing stupid things (e.g. deploying a debug binary to production), but it's, in my opinion, a good way of solving exactly the problem mentioned here.
<a href="http://golang.org/doc/faq#unused_variables_and_imports" rel="nofollow">http://golang.org/doc/faq#unused_variables_and_imports</a><p>The reasons and choices made for this have been fully explained.
I write Go every day, I was going to rant about the author being annoyed minor things (that do not annoy me conveniently), and then it struck me- I'm extremely annoyed by the author wasting a line every time he repeats his code rather than doing this (or something similar depending on case):<p><pre><code> if _, err := ioutil.ReadFile(path); err != nil {
return nil, err
}
</code></pre>
Then I realized, programmers as detailed people are easily annoyed, because small details often matter. But in both the case of the author, and myself here, we need to realize when it truly doesn't matter.<p>Sure these Go behaviours might annoy him, but they are important for large code bases and are easily worked around. Sure, repeating am overly verbose block several times annoys me, but the seven extra lines of code does not make him unreadable or incorrect-<p>Here is too not sweating the small stuff.
Like most opinions about programming languages mine is highly subjective. So viewer discretion is advised:<p>What OP describes is exactly what drove me away from using Go for my 'high level' projects.<p>Now Go is a great language with great ideas but hacking something together in it is such a pain that I don't get a warm feeling when thinking about coding in Go. All those small things add up to where it just gets tiresome. Not something I want experience during programming.<p>There should be some kind of "I know what I'm doing"-mode that lets you import unused packages, etc.
I've found Go to be brilliant in some areas, but very irritating in others. I've lost the link to the talk where Rob Pike describes the reasoning behind the language, but once you understand that they are optimizing for large code bases in large organizations, a lot of these irritating decisions make more sense. In this case, the OP is running up against a trade-off in short-term convenience against long term code hygiene.
yes, Go is a very radical language with very bold decisions in its design and it sure has the "Just Say No" attitude....
but to be honest, its one of the main reasons for me to love Go!! because this makes me sure that Go will not end up like C++ or other bloated languages! you turn your head around, and there is a new feature in language. that sucks.
As someone who has moved to using Go whenever it is possible and reasonably appropriate, I don't find this a particularly large problem.<p>Yes, it's one I encounter, but only once the package is finished and I am in the testing stage and need to debug. Then, the fmt import stays there until I'm done fixing bugs, and I just use gocode's `:Drop fmt` to drop the import. Syntastic, which is a brilliant code validator for vim uses the go compiler to point out every place I have placed an fmt.Println with >>>, allowing me to remove all of them in one fell swoop, where in other languages I would have to search through the code for various print statements. The vanilla Go compiler also points this out, as the author notes.<p>I prefer the way the compiler works because it makes sure your code is always representative of what needs to, and happens.<p>To the author I would say "Why comment out the fmt.Println if you are still debugging?" and "If you are debugging, why only one fmt.Println?".
The solution is to use gdb instead of printing variables in your code for debugging purposes. Go has great gdb support and gdb is a great debugger.<p>There are also multiple editors that support gdb plugins if you don't want to deal with it in its raw form which honestly isn't that bad once you're used to it.<p>I think I could say with a straight face that you will be able to debug a program faster with gdb than sprinkling about print statements even if you didn't have to worry about unused variables.<p>In other words, get used to what the language has to offer and then leverage it before saying it's annoying. The problem you have is 100% solved by gdb.
The objection here is that "I can't hack and hack to get the answer without inconveniencing myself".<p>I watch people using this approach all day every day and have to sort out the shit-tip mess that is left behind because it ends up with sprawling crap.<p>Stop. Think. Write it once. Test it. Fix it. Done.<p>The "think" bit is the most important bit but is lost now that instant feedback is possible in favour of keep changing it until it looks like it works.
While this is incredibly annoying (when trying to write some toy programs in go when it first came out, the 'unused variable' thing hit me so hard until I found out about using _...) I think the 'editor plugins fix this' response is probably the best - but please comment somewhere with a list of editors/plugins that have such intelligent go support so we don't have to roll our own!
(Footnote 1:)<p><i>"Why don't we have a word for this? By "unit of hacking", I mean the work that goes on between starting to hack on a change-set and doing a commit."</i><p>Hackit.<p>As a unit, Ht, similar to Hz for Hertz.<p>(I was going to add it would be named for Jim H. in <a href="http://en.wikipedia.org/wiki/Yes_Minister" rel="nofollow">http://en.wikipedia.org/wiki/Yes_Minister</a> , but his name was Hacker.)
All the inconvenience will be solved if someone built a great IDE. (great like Netbeans for Java or VS for .NET :D, but with someong Gedit or Notepad is great too!)
I think we have a vim puglin function to automatically import/remove.
its open source <a href="https://code.google.com/p/go/source/checkout" rel="nofollow">https://code.google.com/p/go/source/checkout</a> go change it? and a flag or similar on go build and put it to the community?
Good point about having to change the "_, err :=". I have found I have had to cascade changes to ":=" in go programs. I guess it does reduce the pythony feel.
Yeah recently just started on my first go project.. I use hopwatch for debugging and I do end up commenting/uncommenting the module import all the time :/
Why do we keep upvoting these short repetitive rants about Go? There are a half a different posts with this exact same complaint. There are another dozen threads about it on the mailing list with plenty of discussion <i>and</i> it comes up in almost every single comment thread here.<p>Yes, the error handling is explicit. If this is a bother panic/defer+recover is there if you want to use it.<p>The case here is completely contrived; a red-herring. It's not like it's ever typical to do m, err := io.Read... and <i>not</i> use the `m` (if you <i>were</i>, you'd already be writing _, err anyway). Assuming that you write a block of code and then compile it and not write all of your code line-by-line and compile it... and then I guess try to artificially fix the compiler message instead of writing the code to utilize m first?<p>edit: My only point is that this isn't even an issue that arises when normally writing code; the scenario in the blog isn't one that occurs when one sits down, writes a function and then compiles it. Sorry to whoever I upset.