What's funny to me is: if you don't do the add in a loop, go1.8 generates the add code:

    go func() {
        atomic.AddUint64(&a, uint64(1))  // no loop
    }()

To me, it's the unpredictability of how compilers will choose to apply these extreme optimizations that is most frustrating. Reasoning from the spec ("the goroutine might not be scheduled anyway") isn't very satisfying when the compiler clearly doesn't follow logic like this. The implementers reason from the spec and then glue together a mishmash of targeted optimizations--presumably the ones they think will be most helpful.

I suppose many modern modes of programming with composable abstractions result in lots of dead code, and it's a net win for the compiler to aggressively try to get rid of it. With simpler languages like C or Go, though, I might prefer a rule like: "I wouldn't have written the code if I didn't want any instructions generated from it."