> Really, can't I indulge in a sloppy coding style while prototyping something I sympathise with this view, but personally, as a full-time Go programmer, when

> Really, can't I indulge in a sloppy coding style while prototyping something I sympathise with this view, but personally, as a full-time Go programmer, when I've been hacking up little piece of throw-away or explorative code, I've generally found that not-used errors have as often been helpful as annoying. For example, the compiler might say "i not used", and I'll think "bloody compiler, let's delete the declaration", but I'll actually find that I've named a loop variable wrongly and that this would have been a hard-to-find error requiring a few edit-run iterations, and thus I've actually saved more time by doing what the compiler asked than if I'd been able to code sloppily. If I do find myself adding and removing many print statements from within a package, I'll sometimes add a little function: func logf(f string, a ...interface{}) { log.Printf(f, a...) } then as long as that function exists, I can add a logf call to any file in the package with no need to add and remove imports. We can still start with mud, but it's good mud. BTW we have warnings too, but they're generated by a different tool, go vet, which printf format checking and the like.