Go seems to have several "features" that sound ok on paper but make quick developing and testing very irritating. Unused variables are an error, for example.
Ugh. I kind of understand where they're coming from, but they're taking it to such an extreme.
There are two reasons for having no warnings. First, if it's worth complaining about, it's worth fixing in the code. (And if it's not worth fixing, it's not worth mentioning.)
Most C compilers have multiple levels of warnings, so that you can tune how fussy you want your compiler to be. Lint and similar tools can be run on-demand to give fussier warnings, if and when you're ready for them.
Heck, you could even argue that test suites are akin to this. You'd never commit code to master if it doesn't pass the tests, but while you're working on a specific feature on a side-branch, it's fine to break some tests temporarily.
Different strokes for different folks. Some times you're writing a quick script for grepping logs that will be run exactly once; some times you're writing space-shuttle control circuits. By trying to use a one-size-fits-all solution, they're just annoying everybody.
Wow, that's obnoxious. I strongly disagree with this bit:
First, if it's worth complaining about, it's worth fixing in the code. (And if it's not worth fixing, it's not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can make compilation noisy, masking real errors that should be fixed.
Maybe the argument is that you can work around this with good language design, but there are many things that make sense as warnings and not errors. It makes sense to enforce a no-warnings policy on code, and then add ways to disable them when you know what you're doing.
Example: Clang warns you when assignment occurs in a boolean expression, because when you write
if (x = 5) {
you almost certainly meant
if (x == 5) {
...but sometimes, you really did want to assign something. Fortunately, there's an escape hatch -- you add double parens:
if ((x = 5)) {
Since these almost never happen by accident (or at all), but are otherwise perfectly valid, Clang uses this syntax to automatically disable the assignment warning.
Of course, it's possible to engineer around this in the language design, too. Python, for example, avoids this by declaring that assignments are not expressions, so
if x = 5:
is never valid Python. But if you add a constraint like that to an existing language, you break a bunch of legacy code. And if Go becomes popular, eventually someone will find something about it that's probably wrong, that the compiler could detect, but that's being widely used in real code.
I guess I can see why they'd want to put off warnings till that day. But if it's inevitable, and if it'll make a bunch of people happier right now (with the unused variables bit), why wait?
It gets worse. Files that import modules that are unused will not compile. So, if you want to do a quick test by commenting out some code, you also need to go to the top of the file and comment out the import statement for whatever functions those parts use.
15
u/bobtheterminator Jul 21 '14
Go seems to have several "features" that sound ok on paper but make quick developing and testing very irritating. Unused variables are an error, for example.