> 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.