Not at all! This a common impulse among programmers: upon seeing a specific case, you want to make it as abstract and generic as possible. This maximizes the power and flexibility available to the programmer.
However, the design philosophy of Go pulls in the exact opposite direction! Go emphasizes simplicity and large-scale engineering -- i.e. standardization. (gofmt is the canonical example of this.) Giving programmers the power to manipulate the compiler in arbitrary ways would be a nightmare for Go's designers. It opens the door to "clever" code that you tear your hair out debugging 6 months later. The strength of Go is precisely that it makes it difficult to write "clever" code. Go looks pretty much the same everywhere. Which is a little boring, sure; but for me (and many others), that's an acceptable trade-off.
Yeah, keep telling yourself that. Do you actually write code to solve problems yourself or are you more into paying others to do the same? I honestly don't know which alternative would be worst here. What I do know is that this attitude isn't serving us. We're in the business of solving really tricky problems, forcing ourselves to do that using dumbed down tools to protect us from our own intelligence and creativity is insane.
