If you leave out the unpleasant first sentence, I think the post is fine: Once a language becomes popular enough, huge hordes of fad-oriented programmers move

If you leave out the unpleasant first sentence, I think the post is fine: Once a language becomes popular enough, huge hordes of fad-oriented programmers move in and overcomplicate everything to hell and back. See JEE, IoC frameworks, AOP, runtime bytecode modification, patterns out the wazoo, OOP hierarchies, etc. I think Go was deliberately designed to sabotage some of these attempts, and thus far it's been successful at staying uncomplicated. I hope it has managed to build enough of the immune system for fads to not get much traction. Stay boring and simple, Go. I like my tools boring and simple. Most languages are designed with technical power/semantic guarantees while writing code as the primary goal. However, programmer-oriented HID accounting proportionally for all parts of the edit-test-debug cycle and production/maintenance should really be the first priority. I think that all successful languages that get pooh-poohed for being boring, being Blub, or being technically inferior must be doing something right when it comes to the above. Think about it. Do we know of any other products where people have a misguided narrow focus on "specs," but which can be improved tremendously by thinking about the overall experience? Laptops, cars, and apps come to mind. Why shouldn't such a principle also apply to development stacks?