Go language warnings and errors

It seems that GO language does not have warnings in it. I've observed
few instances.

1. "declared and not used"(if variable is declared and not used
   anywhere it gives an error and does not compile the program)
2. "imported and not used"(similarly if package is imported and not
   used anywhere it gives an error and does not compile the program)
   Can somebody help. If they have any pointers.

Go is trying to prevent this situation:

> The boy is smoking and leaving smoke rings into the air. The girl gets
> irritated with the smoke and says to her lover: "Can't you see the
> warning written on the cigarettes packet, smoking is injurious to
> health!"
>
> The boy replies back: "Darling, I am a programmer. We don't worry
> about warnings, we only worry about errors."

Basically, Go just wont let you get away with unused variables and unused imports and other stuff that is normally a warning on other languages. It helps put you in a good habit.

> The Go Programming Language
> FAQ
>
> Can I stop these complaints about my unused variable/import?
>
> The presence of an unused variable may indicate a bug, while unused
> imports just slow down compilation. Accumulate enough unused imports
> in your code tree and things can get very slow. For these reasons, Go
> allows neither.
>
> When developing code, it's common to create these situations
> temporarily and it can be annoying to have to edit them out before the
> program will compile.
>
> Some have asked for a compiler option to turn those checks off or at
> least reduce them to warnings. Such an option has not been added,
> though, because compiler options should not affect the semantics of
> the language and because the Go compiler does not report warnings,
> only errors that prevent compilation.
>
> There are two reasons for having no warnings. First, if it's worth
> complaining about, it's worth fixing in the code. (And if it's not
> worth fixing, it's not worth mentioning.) Second, having the compiler
> generate warnings encourages the implementation to warn about weak
> cases that can make compilation noisy, masking real errors that should
> be fixed.
>
> It's easy to address the situation, though. Use the blank identifier
> to let unused things persist while you're developing.
>
> import "unused"
>
> // This declaration marks the import as used by referencing an
> // item from the package.
> var _ = unused.Item // TODO: Delete before committing!
>
> func main() {
> debugData := debug.Profile()
> _ = debugData // Used only during debugging.
> ....
> }

One solution for unused imports is to use goimports, which is a fork of gofmt. It automatically adds missing imports and removes unused ones (in addition to formatting your code).

http://godoc.org/code.google.com/p/go.tools/cmd/goimports

I've configured my editor to automatically run goimports whenever I save my code. I can't imagine writing go code without it now.

From what I just read, (wikipedia)
"Go's syntax includes changes from C aimed at keeping code concise and readable."

The word "concise" is very important to the compiler. I have found out
that the syntax enforced by the compiler is no longer "\n" or whitespace
agnostic. And there are no "warning" type errors.

There are good things about Go. There are some not so good things. The
attitude of no warnings is a bit extreme, especially when developing or testing
a new package. It seems that partial development is not acceptable. Warnings are not acceptable. It is either the production version or the highway. This is a very dualistic point of view. I wonder if evolution would have resulted in "life", if that had been the constraints on nature.

I can only hope that things will change. Death seems to be very beneficial at times.
I have tried Go, and I am disappointed. At my age I don't think I will return.