They are legitimate concerns, but your given example (re-ordering constants) could break other things silently in any case. There's always a line between risk and convenience. For some people Go is too conservative, and for others it is too liberal.
It is just extremely frustrating to see them using contradictory arguments for various parts of the language. This is a very liberal way to do this, which contradicts most of the rest of the language (library dependencies, language itself, features).
For instance in this case, the very existence of the code generation libraries contradicts the reflection package.
Compile-time function execution would have been so much more consistent it's horrifying :
But like every other decision in Go, you can either assume the Go developers actually believe the arguments they're putting up ... or you can ask yourself "would the Go compiler/toolchain become easier or harder to implement ?" And use that argument as almost the sole argument for any decision. One of these ways of thinking explains every decision very consistently, the other leaves one listing the exceptions.
And the right solution, mixins + CTFE is legendary hard to implement. As in, someone who's written 3 commercial C++ compilers from scratch has serious trouble getting it to work.
> And use that argument as almost the sole argument for any decision. One of these ways of thinking explains every decision very consistently, the other leaves one listing the exceptions
That's not accurate. There are a lot of things about Go that are very difficult to implement. The concurrency system and garbage collector are obvious examples. Some less obvious ones are discussed here: http://talks.golang.org/2014/compiling.slide
Conclusion
Go is simpler to compile than most languages
There are still complexities for the compiler
Most complexities stem from making Go easier to write
I would also argue that if you take a compiler book, and you look up these problems, they're all solved. That is certainly not true for most other languages such as Prolog, Haskell, Java, Rust or D, especially not at the time they were written. Most of those added a chapter or two to our knowledge of compilers. Or ten, in the case of Haskell.
