4 ms·

I was hoping for something more fundamental. That feels like sacrificing function for form

by fhood 10y ago

jameskilton 10y ago
I don't understand. What's being sacrificed? Of what use is a list of imports that aren't used?
- kormoc 10y ago
  Efficient copypasta
- fhood 10y ago
  You have never commented out a section of code that was the only place an import was used for debugging?
  - jameskilton 10y ago
    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.
  - imauld 10y ago
    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.
danwakefield 10y ago
Switch out gofmt for goimports (https://github.com/bradfitz/goimports https://github.com/bradfitz/goimports) to fix the errors on save with your editor / ide
brianwawok 10y ago
You require crap all over your code that doesn't do anything?
AnimalMuppet 10y ago
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.

I was hoping for something more fundamental. That feels like sacrificing function for form

by fhood 10y ago

I was hoping for something more fundamental. That feels like sacrificing function for form

jameskilton 10y ago

I don't understand. What's being sacrificed? Of what use is a list of imports that aren't used?

kormoc 10y ago
Efficient copypasta
fhood 10y ago
You have never commented out a section of code that was the only place an import was used for debugging?
- jameskilton 10y ago
  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.
- imauld 10y ago
  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.

danwakefield 10y ago

Switch out gofmt for goimports (https://github.com/bradfitz/goimports https://github.com/bradfitz/goimports) to fix the errors on save with your editor / ide

brianwawok 10y ago

You require crap all over your code that doesn't do anything?

AnimalMuppet 10y ago

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.