42 ms·

From looking at what the Go team had to say about Go in its earliest days, Go had very little to do with Java, and they weren't very concerned with fixing Java'

From looking at what the Go team had to say about Go in its earliest days, Go had very little to do with Java, and they weren't very concerned with fixing Java's issues. The "Bloated Abstractions" issue in Java is more of a cultural thing than an issue of the language. You could even say it's partially because early Java (especially before Java 1.5) was too much like Go! Java used to have the same philosophy around abstractions, and Sun/Oracle were pretty conservative about adding new language features. To compensate for lack of good language-level abstractions, Java developers used complicated techinques and design patterns, for example: 1. XML configuration, because there were no attributes. 2. Attributes because there were no generics and closures. 3. Observers/Visitors/Strategies/etc. because there weren't any closures. 4. Heavy Inheritance, because there was no delegation. 5. Complicated POJOs and beans, since Java didn't have properties or immutable records.

yencabulator 3y ago
Many other software development cultures lived through similar limitations without evolving to the levels of abstraction astronaut achievement award of Java. No other language comes close to this: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
- unscaled 3y ago
  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/

yencabulator 3y ago

Many other software development cultures lived through similar limitations without evolving to the levels of abstraction astronaut achievement award of Java. No other language comes close to this: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

unscaled 3y ago
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/