One under-appreciated consequence is that this policy limits Go to one implementation. Say I write an alternative implementation of Go, that has a different "unreachable code" detector. If I issue errors on new cases, then I'm incompatible with lots of existing Go code. If I fail to issue errors, then code developed against me may be incompatible with the standard Go. The effect is to suppress alternative implementations.
Better to just put my smarts into a linter, which is then just reinventing compiler warnings under a different guise.
I already mentioned that case. To be more clear: Let it not build with default options. Make it not `go get`able.
Let me develop first, and not force me to optimize prematurely.
I'd argue that cleaning unused code as you work isn't optimisation. It's a part of the refactoring process of development which is something that must happen during the main development phase.
But arguments for and against aside, most developers don't see these kinds of compiler errors that often as you'd generally be commenting out unwanted code while you're prototyping. The biggest annoyance is easily the imports and pragmatically that still takes up such an insignificant amount of effort when compared with the overall time spent writing code in any particular language. Which is why many Go advocates are willing to put up with it.
How is it refactoring if my code never builds in the first place?
> pragmatically that still takes up such an insignificant amount of effort when compared with the overall time spent writing code in any particular language. Which is why many Go advocates are willing to put up with it.
It's not a time problem. It's a focus problem. I'm working on something and then out of nowhere, receive compilation errors, which aren't urgent at all, but they distract me anyway. Even if this were indeed a very small problem, I still don't see why something most people see as a problem is pushed down the developers throat with false, dogmatic reasoning. Don't get me wrong: I have huge respect to the people who created go. I just don't like when people defend all the choices they made as "one true way".
Why would you be typing in imports that you've never used? I guess that could happen, but the more likely scenario you had used them at some point, even if just briefly, and then you're refactoring the code.
> It's not a time problem. It's a focus problem. I'm working on something and then out of nowhere, receive compilation errors, [...] pushed down the developers throat with false, dogmatic reasoning
Please don't be so melodramatic. It doesn't happen "out of nowhere" - you've purposely requested the compiler runs. And if you're compiling then you're doing so to either test your code compiles or test it runs - in either case your focus has already intentionally shifted from writing code to testing and debugging it.
> Don't get me wrong: I have huge respect to the people who created go. I just don't like when people defend all the choices they made as "one true way".
I'm not defending it. I'm saying people are being melodramatic about the actual inconvenience it causes. In all of the years I've been writing Go, I think I've spent just as much time coding around that annoyance than I've spent in this thread chatting about it. The difference being, occasionally that annoyance is useful where as the internet arguments about it literally serves no benefit to anyone.
No, I'm compiling to see if my changes still allow the tests to pass. This is a huge problem if you're doing TDD. The main argument you make is that it's not such a big problem and I think the number of people complaining says otherwise. Or maybe we developers just like being melodramatic. I honestly can't tell. Maybe what triggers such passion is go being very close to a perfect tool for certain things and those annoyances look like small black dots in a perfectly white surface (That sounded dramatic as well, what's wrong with me? :) )
Isn't it implied that programmers are adults?
I can't say I blame Rob Pike for not trusting developers, and I've definitely seen more than one case of a C/C++ codebase riddled with thousands of compiler warnings that were just ignored en masse during compilation.
There is another side of the coin, which is that experienced and disciplined developers who think they can take care of themselves, thankyouverymuch, would end up feeling limited by Go.
It's one of those irregular situations:
I'm a senior developer.
You're an adult programmer.
He's a stark raving juvenile lunatic.
The point about alternative implementations is interesting. Java has a comparable situation with unreachable code; the language specification has a simplistic definition of what unreachable code is, and makes it a compile-time error. A smart compiler can find more cases of unreachable code, but isn't allowed to make them errors. So it makes them warnings. It doesn't seem to be a big impediment to alternative implementations in practice.
There is a cost to this too. It is another option. Another thing to document and maintain. Another thing for developers to learn about. Another thing for newbies to be confused by. Another thing that will asked about on the mailing list.
For example, most JS linters do that check and as a general rule, the build servers would reject the commit when the linter complains. I actually have a (very hacky) plugin to ESLint that automatically removes unused variables before `hg push`. It's totally not optimal, as in, you can still run/compile/transpile/whateverify the code with default options, but a language with no backwards compatibility worries can just add a flag to override strict checks to make a developers life easier, can't it?
I understand not implementing something that perhaps may not fit the language well or is so complicated that it really needs a lot of thought (read: generics). But this decision seems to be dogmatic at best.
I have the exact love/hate relationship with Go as the author of the article.