6 ms·

They can produce a warning on unused stuff, instead of an error and not force this idea on everyone, especially considering they have zero proof on this idea.

• eikenberry 13y ago
  https://github.com/elazarl/gosloppy https://github.com/elazarl/gosloppy
• scott_s 13y ago
  Go is a rather opinionated language. They could produce a warning, but then with large projects, one has to decided, should all warnings be made errors? Will there be exceptions to the rule? They simplified that for large projects by making one decision, and forcing it on everyone. (Please note that I am explaining what I think their motivations are. I am not arguing for the perspective.)
• viscanti 13y ago
  What's the argument for allowing un-used imports? I've never run into a case where I wished I had imported something but didn't want to use it If you're looking at future code, you can accomplish that by commenting out the import. But I've never run into the situation where writing future code has been good, or where I wouldn't have remembered to import the package I needed when I wrote that code. If you really need to import packages you're not using, and for some reason can't spend the time to comment those out, GO probably isn't for you. I just haven't heard of a case where doing otherwise would have been helpful.
  • zzzcpan 13y ago
    I don't know how people write their code, but I don't like thinking about satisfying compiler when I'm working on some idea, it takes some of my thinking power. I'd rather do that later, probably together with unit tests.
  • jlarocco 13y ago
    I think this is a matter of the way an individual person writes code, and not something that can be generalized by saying "this is never useful" or "this is always useful". Some people will find it annoying, others not. I personally find it annoying because I compile often. In my workflow I write code for a few minutes then compile it and run some quick tests or even run it through the debugger to make sure everything is working the way I expect. If everything checks out I start on the next bit. I may be adding a feature that I know in advance will use libraries xxx, yyy, and zzz. The natural thing to do is to add those imports when I open the source files that will use them, then get to work implementing the feature. Another useful reason is to import a library just to make sure it's installed correctly, before writing the code that uses it, although that's less common.
  • deleted 13y ago
    [deleted]
  • ridiculous_fish 13y ago
    Say you're trying to debug something, and you add a call to fmt.Printf. 'Compile error, "Undefined: fmt."' No problem, add 'import "fmt"' at the top. Now it's debugged, so let's remove the annoying logging statement. Oops: 'Compile error: "imported and not used: fmt."' So now you remove the import, knowing full well you're going to be adding it back again in a minute or two. Annoying! Or maybe, as part of debugging, you temporarily comment out a block of code. You just made a bunch of variables and imports unused, and you can't even test your changes until you clean them up. Exploratory programming and debugging puts code in transiently dirty states, and Go's enforced hygiene is onerous in those cases.
• jff 13y ago
  People ignore warnings. Want proof? Go grab damn near any open source project and compile it. It's almost guaranteed that the default compile options, chosen by the authors, will generate dozens if not hundreds of warnings. Everyone's so very noble at the start of a project, "We shall turn on all warnings, and then fix them!", but really once the program compiles and seems to run properly, all that goes out the window.
  • zzzcpan 13y ago
    Perl is one example, where people usually have all warnings enabled and keep their code warning-free. I guess it depends on the community.
  • ridiculous_fish 13y ago
    This is largely due to compiler version differences. I can fix every warning my compiler emits, and you are likely to still get warnings on yours. Go's enforced -Werror can work in a smallish community, where there's a single compiler and a culture of everyone always using its latest version. But I don't see how it can survive an environment where there's multiple compilers, each with multiple versions. Who here could write a C program that is guaranteed to never produce a warning on any C compiler?
• cynwoody 13y ago
  I agree. I would like an option to have unused imports and variables ignored during development. But I would also like them gone in the final code, because they are noise inhibiting future human understanding of the code. It might also be useful to have gofmt auto-remove unused imports and variables.
• scott_s 13y ago
  Take a look at this adaptation of a keynote talk on the design of Go, with the title "Language Design in the Service of Software Engineering": http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article Section 7, "Dependencies in Go" addresses this issue: http://talks.golang.org/2012/splash.article#TOC_7 http://talks.golang.org/2012/splash.article#TOC_7. The relevant paragraph states, The first step to making Go scale, dependency-wise, is that the language defines that unused dependencies are a compile-time error (not a warning, an error). If the source file imports a package it does not use, the program will not compile. This guarantees by construction that the dependency tree for any Go program is precise, that it has no extraneous edges. That, in turn, guarantees that no extra code will be compiled when building the program, which minimizes compilation time.
  • zzzcpan 13y ago
    Compiler can ignore unused dependencies and variables, since it detects them anyway and still guarantee that no extra code will be compiled when building the program, which minimizes compilation time. So the argument itself is flawed and only gives a perception of rational decision, while not actually being rational.
    • scott_s 13y ago
      The compiler cannot ignore an unused dependency. The compiler must first process the imported packages, then compile the current package. It only knows that an imported package was not used until after it has finished compiling the entire current package.
      • zzzcpan 13y ago
        I don't know how Go compiler works, but I don't see a problem detecting unused dependencies very early just by walking an AST of current package, since in Go you have to specify package name explicitly in order to use something from it (well, not all the time, but almost all the time). And even this is probably unnecessary, you only have to process additional unused dependencies in your current package, other packages already did. Anyway, it's just a technical problem with a few simple solutions.
• Roboprog 13y ago
  It makes it easier for me to read your code when I checkout a copy: there's not a bunch of unused cruft I have to mentally skip over to look at it. You'll be glad later that I'm not leaving a bunch of left over Rob's stupid crap (TM) that you have to wade through as well :-) It's not just imports, assigned-but-not-used is also a failure. This keeps the cruft down.