I came across this article "Go Is Not Java". Here are my thoughts.

Design Patterns

• For programmers using objected-oriented languages, I would recommend all to learn Design Patterns. Refactoring Guru is a good place to start. Of course Design Patterns: Elements of Reusable Object-Oriented Software is a book worth keeping.

• It is important to know when to apply the patterns, and equally important to know when it is not applicable.

• Design Patterns are not a sliver bullets, it will not solve all your problems. But for the right problems, they provide elegant solution keeping your code adaptable to future changes.

• Design patterns are typical solutions to common problems in software design. Each pattern is like a blueprint that you can customize to solve a particular design problem in your code.
  - https://bit.ly/3xZ74Xn

  Design pattern is not just for object-oriented languages. You can create patterns for non object-oriented languages too. Of course the patterns by GoF (Gang of Four) is mainly targeted at object-oriented languages.

OOP

• Go is not an object oriented language. It is flexible enough to allow you to use it like one but it is not design to be an objected oriented language.

• Go has its way of doing things. Some people, in the name of Design Patterns, try to turn Go into Java/C#. If Go can solve a problem elegantly, there is no need to force Java-style Design Patterns on Go.

• Object Oriented programming is actually not even about the Objects it is about message passing.

  Originally, the core principle of OOP is messaging passing. But this is rarely taught in school, and long forgotten. Nowadays, people tend to focus on "object" part of OOP.