Very true, and Go (or bash for that matter) are proofs that language limitations do not mandate complexity. Complexity is mandated by perceived need and culture

Very true, and Go (or bash for that matter) are proofs that language limitations do not mandate complexity. Complexity is mandated by perceived need and culture. You can easily see how complexity would play out in Go by looking at Kubernetes. Most projects did not fall into the complexity trap, but there are many differences in form, functions and context: - Early Java projects before Java EE (like Applets and early GUI apps) did not have this level of complex abstraction. The code wasn't great (old Java APIs like StringBuffer and Date were often quite horrible), but it was simple. - Java started getting complex with J2EE. J2EE was strongly motivated by enterprise requirements for interoperability and dynamically configurable and interchangeable components. - Another source of complexity was the popularity of XML and the widespread belief (back in the early 2000s) that moving part or all of your business logic to XML was a good thing. - And then there was the design patterns obsessions, where design patterns transformed from being a common pattern observed in code into something that should be emulated. - Most of the early J2EE complexity is dead (EJBs, XML configuration, CORBA, SOAP), but many users don't want to give up component interoperability and powerful dynamic configuration. That's why Java frameworks like Spring, Java EE and even modern frameworks like Quarkus or Micronaut have all their annotations and implicitness. - Go was luckier(?) to be born in a different time and popularized in a different context. - There was no top-down enterprise-oriented backing for Go (even within Google, it was a bottom up project). - The Go compiler, runtime and libraries were fully open-source from day one, under a permissive license. Third party libraries were also almost universally open source. The existence of open source culture made concerns about vendor lock-in moot, and interchangeability was not a thing. - The XML hype died and there was a consensus that component wiring should be done in code. - Many of us got sober on design patterns. Peter Norvig's critique[1] gained traction outside of the LISP community and the anti-design pattern view became dominant within the dynamic language community as well, even in strongly OO languages like Ruby. This is the community that was feeding Go. - Most servers written in Go were just smaller in scope than the equivalent Java projects. This has many causes (less top-down big-rewrite enterprise projects, microservices gaining popularity, UI logic usually moving to front-end or mobile app). [1] http://norvig.com/design-patterns/ http://norvig.com/design-patterns/