I am very curious as to why this particular "feature" was implemented in the language. I find it very annoying and was wondering if there was a logic to its inclusion in the language.
Of course I have. That's not a good reason for the compiler to allow the unused imports. The benefits of Go's strict compilation rules far outweigh the periodic pain points.
Sure.
I also use Atom with gofmt installed (the Atom gofmt package allows you to use goimports as a formatter). Comment the line and hit save and the import goes away. Uncomment and hit save and it comes back. Tools exist to make dealing with this requirement painless.
It's about very long-lived projects (and at least partly about compile time).
Fundamentally, Go was aimed at huge code bases (think ten million lines) that live for decades. C++ code of that size takes a long time to compile (45 minutes to a few hours). If you have 30 people working on a project, and they each compile a few times a day, over 20 years that adds up to a huge amount of time.
One of the issues with C++-style includes is that they slow down compile times, because you see the same file over and over, and only process it the first time, and the rest of the time you import the text but don't do anything with it. But the compiler has to wade through all that unused text. So Go said, not just that you can only have the imports that you need, but also that you can't have cycles in the imports.
Now, from where I sit, the "no cycles" is much more clearly related to compile times than "no unused" is. But I think that they both come out of the same philosophy: "We're not going to permit less-than-optimal stuff to accumulate in the imports, because over the long run of a project, it bites you". It bites you in that, as time goes on, it becomes harder and harder to fix, and because it makes the compiles slower and slower.
10 comments
[ 2.8 ms ] story [ 36.7 ms ] threadKeeping code clean. If you can't compile with unused imports/variables, you can't forget them.
Fundamentally, Go was aimed at huge code bases (think ten million lines) that live for decades. C++ code of that size takes a long time to compile (45 minutes to a few hours). If you have 30 people working on a project, and they each compile a few times a day, over 20 years that adds up to a huge amount of time.
One of the issues with C++-style includes is that they slow down compile times, because you see the same file over and over, and only process it the first time, and the rest of the time you import the text but don't do anything with it. But the compiler has to wade through all that unused text. So Go said, not just that you can only have the imports that you need, but also that you can't have cycles in the imports.
Now, from where I sit, the "no cycles" is much more clearly related to compile times than "no unused" is. But I think that they both come out of the same philosophy: "We're not going to permit less-than-optimal stuff to accumulate in the imports, because over the long run of a project, it bites you". It bites you in that, as time goes on, it becomes harder and harder to fix, and because it makes the compiles slower and slower.