I had a very interesting conversation with a fellow developer a while back. He has a background in building engineering, and told me the following story:

1. Architect designs a building.
2. The building engineer tells the architect “you really need to make this column three times as wide, or otherwise the roof will collapse”.
3. The architect says: “Aww, but it ruins my Feng-Shui”.
4. The final building is constructed from the compromises that the architect and the building engineer agreed on.
5. People believe that the whole building was built single-handedly by the architect.

He said that what people in Computing Science call ‘design patterns’ (probably since the famous ‘design patterns’ book written by the ‘gang of four’) are actually ‘structural patterns’: “build the column this way or the roof caves in.”.

As such, they have nothing to do with beauty, but everything with practicality (which, in computing science, translates to speed/memory efficiency, ease-of-understanding, ease of refactoring).
Many programmers boast that “they solved problem A by using patterns X, Y and Z”, but that is useless. Patterns are something to recognize and use when it is useful to do so, not something to boast over or to cram as many as possible in your application of.

In the end, the main use of these named patterns is that two developers can have a conversation about a possible solution for a problem, and easily describe to each other how these work in general terms, just like two architectural engineers might converse and say: “to prevent this wall from collapsing, we could use a buttress.”

Tl;Dr: do not use patterns to solve a problem. do solve a problem by using patterns.
Patterns are good nor bad, but programming is about solving problems, not about cramming as many patterns as possible in your codebase.

As for the ‘do patterns exist in functional programming?’-debate: Yes, they do! (To be exact, structural patterns do). Some common ones include recursion, map/reduce, higher-order functions and even the illustrious monads. However, these patterns have a much lower impact on how everything around them is designed than many of the OOP-patterns are, and all of these patterns more-or-less arise naturally (i.e. even when you do not know about them, you might already have ‘reverse-engineered’ them).

The fact that many people do not recognize these as patterns might indeed mean that it is so natural to use them in your language, that indeed they can be considered language features.

As for OTP: Message-passing is a complex thing. OTP packages this in the best way Erlang could. I completely agree that this does not feel like the most idiomatic way in all circumstances.

There do exist Elixir libraries that wrap GenServer & friends using macros to make it easier to use, such as ExActor. This works fine for 95% of the cases. For the other cases (more logic in the outward-facing function before calling handle_*, or needing to keep the dependencies of your library as small as possible) simple OTP is fine.

I would say that behaviours are something completely different from structural patterns: Behaviours make different parts of your code agree in what way something can communicate. This in no way restricts what else is going on in those parts of your code.

Finally though, recognizing patterns is actually important. This amazing TED-talk explains why better than I could :

Thank god someone said it.

Patterns being a bad thing is something that seems to be perpetuated by people who got burned because they took the idea of design patterns and “best practices” to mean “use all the time”, and then get mad when their square peg doesn’t fit in their circular hole, and they had to do frankenstein work to make it fit.

Formal design patterns are just a way to communicate different architectural approaches to solving a specific problem, not even to architect a whole application.