4 ms·

> > Notably, if a package is included but not used, Go treats this as an error and enforces removing unused declarations A good illustration that the Go design

by laureny 14y ago

> > Notably, if a package is included but not used, Go treats this as an error and enforces removing unused declarations A good illustration that the Go designers didn't think their ideas through. This is a real pain in the butt when you are writing code and regularly commenting in and out sections of code while you are testing things. And every time you do this, you need to remove or restore the imports. And since Go's tooling is nonexistent, there is no IDE to do this automatically for you. This kind of thing belongs in a compiler plug-in (if it was designed with such a thing in mind, which is not the case for Go), macros (if the languages supports them, ideally the hygienic and statically typed kind) or an external tool, not in the compiler.

burntsushi 14y ago
> A good illustration that the Go designers didn't think their ideas through. Please don't misconstrue disagreement as sloppiness. If you read the mailing list, it's pretty clear they thought it through. > This is a real pain in the butt when you are writing code and regularly commenting in and out sections of code while you are testing things. Not for me. I love it, actually. > And since Go's tooling is nonexistent, there is no IDE to do this automatically for you. Vim does this for me. Also, Go has some of the most wonderful tools of any programming language I've ever used. > This kind of thing belongs in a compiler plug-in (if it was designed with such a thing in mind, which is not the case for Go), macros (if the languages supports them, ideally the hygienic and statically typed kind) or an external tool, not in the compiler. I think reasonable people can disagree on this point.
jbarham 14y ago
False. The Go designers have explained many times why they made unused imports an error. In particular unused dependencies slow down compilation. There's even a FAQ: http://golang.org/doc/faq#unused_variables_and_imports http://golang.org/doc/faq#unused_variables_and_imports. A trivial workaround to silence the compiler errors during development is to use blank identifiers (http://golang.org/doc/effective_go.html#blank_unused http://golang.org/doc/effective_go.html#blank_unused). I use them all the time. You may disagree with their decision, but it's disingenuous to claim that it's because they didn't think it through.
- WayneDB 14y ago
  Maybe they did think it through, but their conclusion reveals some inexperience. It's impractical on many levels. Thus the need for kludgy solutions like blank identifiers. I'd rather see a strict mode or some other type of compiler flag.
  - jbarham 14y ago
    Maybe you don't realize that "they" includes Ken Thompson himself... You may disagree with the Go design team's decisions, but it's amusingly absurd to accuse them of inexperience.
    - laureny 14y ago
      > Maybe you don't realize that "they" includes Ken Thompson himself... You may disagree with the Go design team's decisions, but it's amusingly absurd to accuse them of inexperience. Not really, if anything, Go shows that its designers have a lot of inexperience when it comes to modern language design. Go would have been a kille language in the late 90's but it seems to ignore everything that we've learned about language design in the past decade.
      - pjmlp 13y ago
        Quite true, every single feature can be traced back to 80's and 90's languages that for whatever reason did not manage to become mainstream. Maybe one could make a table stating the language feature and which language provided it for the first time.
        pjmlp 13y ago
        Just an update on my comment. Even if the language is like that, if it helps improving the situation where young developers learn that strong typing does not have anything to do with VMs, I find it quite positive.
    - pjmlp 13y ago
jussij 14y ago
> good illustration that the Go designers didn't think their ideas through. This is a real pain in the butt when you are writing code and regularly commenting in and out sections of code while you are testing things. How could it be that bad? It's as simple as a compile, a click on the error message and adding a one line comment. No worse than the standard practice of making sure your c/c++ code compiles without warnings with the maximimum warning level set.
- lobster_johnson 14y ago
  People develop at different speeds. For me, anything like this that slows me down and interrupts my flow with 3-4 seconds of "click on the error message and add a one-line comment" is incredibly annoying. Development has several modes. One mode is "hacking", just hashing out what you want until it works and is elegant enough as a solution, perhaps changing your mind frequently when you see how it works in practice. Another is "polishing", carefully annotating, cleaning up, documenting, burning off loose threads, making sure the test coverage is top notch, etc. The problem is that Go's compile-time strictness lends itself to the "polishing" phase, but not to the "hacking" phase.
  - redbad 13y ago
    > Development has several modes. One mode is "hacking", > just hashing out what you want until it works and is > elegant enough as a solution, perhaps changing your mind > frequently when you see how it works in practice. > Another is "polishing", carefully annotating, cleaning > up, documenting, burning off loose threads, making sure > the test coverage is top notch, etc. > > The problem is that Go's compile-time strictness lends > itself to the "polishing" phase, but not to the > "hacking" phase. When I write Go, or indeed in any programming language, I generally start with, and stay in, what you call the "polishing" phase. Experimentation occurs in my head, and what makes it through to my fingers is the polished form of that experiment. That Go is not conducive to writing sloppy (or "hacking" phase) code is I think only a good thing.
    - 13y ago
kragen 13y ago
Jesus Jumping Blue Christ, why is it that every time Golang comes up in any type of discussion, there's always someone out there who complains that Go is horrible because it doesn't implement their favorite pet non-mainstream language features, which is obviously because the Go designers were inexperienced newbies with only 50 years of experience designing groundbreaking software, and therefore lacked your deep insights into how things should really be organized?
- stock_toaster 13y ago
  I usually chalk it up to armchair quarterbacking.

by laureny 14y ago

burntsushi 14y ago

> A good illustration that the Go designers didn't think their ideas through. Please don't misconstrue disagreement as sloppiness. If you read the mailing list, it's pretty clear they thought it through. > This is a real pain in the butt when you are writing code and regularly commenting in and out sections of code while you are testing things. Not for me. I love it, actually. > And since Go's tooling is nonexistent, there is no IDE to do this automatically for you. Vim does this for me. Also, Go has some of the most wonderful tools of any programming language I've ever used. > This kind of thing belongs in a compiler plug-in (if it was designed with such a thing in mind, which is not the case for Go), macros (if the languages supports them, ideally the hygienic and statically typed kind) or an external tool, not in the compiler. I think reasonable people can disagree on this point.

jbarham 14y ago

False. The Go designers have explained many times why they made unused imports an error. In particular unused dependencies slow down compilation. There's even a FAQ: http://golang.org/doc/faq#unused_variables_and_imports http://golang.org/doc/faq#unused_variables_and_imports. A trivial workaround to silence the compiler errors during development is to use blank identifiers (http://golang.org/doc/effective_go.html#blank_unused http://golang.org/doc/effective_go.html#blank_unused). I use them all the time. You may disagree with their decision, but it's disingenuous to claim that it's because they didn't think it through.

WayneDB 14y ago
Maybe they did think it through, but their conclusion reveals some inexperience. It's impractical on many levels. Thus the need for kludgy solutions like blank identifiers. I'd rather see a strict mode or some other type of compiler flag.
- jbarham 14y ago
  Maybe you don't realize that "they" includes Ken Thompson himself... You may disagree with the Go design team's decisions, but it's amusingly absurd to accuse them of inexperience.
  - laureny 14y ago
    > Maybe you don't realize that "they" includes Ken Thompson himself... You may disagree with the Go design team's decisions, but it's amusingly absurd to accuse them of inexperience. Not really, if anything, Go shows that its designers have a lot of inexperience when it comes to modern language design. Go would have been a kille language in the late 90's but it seems to ignore everything that we've learned about language design in the past decade.
    - pjmlp 13y ago
      Quite true, every single feature can be traced back to 80's and 90's languages that for whatever reason did not manage to become mainstream. Maybe one could make a table stating the language feature and which language provided it for the first time.
      - pjmlp 13y ago
        Just an update on my comment. Even if the language is like that, if it helps improving the situation where young developers learn that strong typing does not have anything to do with VMs, I find it quite positive.
  - pjmlp 13y ago

jussij 14y ago

> good illustration that the Go designers didn't think their ideas through. This is a real pain in the butt when you are writing code and regularly commenting in and out sections of code while you are testing things. How could it be that bad? It's as simple as a compile, a click on the error message and adding a one line comment. No worse than the standard practice of making sure your c/c++ code compiles without warnings with the maximimum warning level set.

lobster_johnson 14y ago
People develop at different speeds. For me, anything like this that slows me down and interrupts my flow with 3-4 seconds of "click on the error message and add a one-line comment" is incredibly annoying. Development has several modes. One mode is "hacking", just hashing out what you want until it works and is elegant enough as a solution, perhaps changing your mind frequently when you see how it works in practice. Another is "polishing", carefully annotating, cleaning up, documenting, burning off loose threads, making sure the test coverage is top notch, etc. The problem is that Go's compile-time strictness lends itself to the "polishing" phase, but not to the "hacking" phase.
- redbad 13y ago
  > Development has several modes. One mode is "hacking", > just hashing out what you want until it works and is > elegant enough as a solution, perhaps changing your mind > frequently when you see how it works in practice. > Another is "polishing", carefully annotating, cleaning > up, documenting, burning off loose threads, making sure > the test coverage is top notch, etc. > > The problem is that Go's compile-time strictness lends > itself to the "polishing" phase, but not to the > "hacking" phase. When I write Go, or indeed in any programming language, I generally start with, and stay in, what you call the "polishing" phase. Experimentation occurs in my head, and what makes it through to my fingers is the polished form of that experiment. That Go is not conducive to writing sloppy (or "hacking" phase) code is I think only a good thing.
  - 13y ago

kragen 13y ago

Jesus Jumping Blue Christ, why is it that every time Golang comes up in any type of discussion, there's always someone out there who complains that Go is horrible because it doesn't implement their favorite pet non-mainstream language features, which is obviously because the Go designers were inexperienced newbies with only 50 years of experience designing groundbreaking software, and therefore lacked your deep insights into how things should really be organized?

stock_toaster 13y ago
I usually chalk it up to armchair quarterbacking.