Why many Gophers eschew Java

If you like design patterns, use Java, not Go.

Let's think about where this thinking comes from. Java (as well as C++) tends to focus on type hierarchies and type taxonomies.

Take the ObjectRetrievalFailureException class from the Spring Framework for example:

This looks far too complicated and over-abstracted, right?

Unlike Java, Go is designed to be a pragmatic language where we won't get lost in infinite levels of inheritance and type hierarchies.

When we implement a solution in a language that places so much emphasis on a type hierarchy, levels of abstractions, and class inheritance, our code refactorings tend to be much more time-consuming. It's best to get the design right before we begin coding. Leveraging design patterns can save a lot of time when implementing Java solutions.

Inheritance creates a high level of coupling in object-oriented programming. In the preceding example, a change in the DataAccessException class could cause unwanted side effects in every class above it in the hierarchy.

It's easy to see why anyone might think there is no place for design patterns in Go.

"If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition."

- Rob Pike

However, with careful use of abstraction, software design patterns can be entirely compatible with Go's composable simple design philosophy.