First, I want to echo what @keathley and @peerreynders had to say. They covered a lot of good ground pretty thoroughly, so I’m going to take another direction in trying to answer your question.
I’d like to start by making a distinction between design patterns and design principles.
The Gang of Four book is probably the most famous source of design patterns, but the architectural patterns you mentioned - hexagonal and onion - are as well. My sense of design patterns is that they’re fairly strict. There are rules to follow. There are definitions and technical terms to learn.
Design principles are more loose and general. These are often just phrases like “build in layers”, “minimize complexity”, “name things expressively”, and so on.
Design principles most often use common terms with their everyday meanings. They tend not to emphasize hard and fast rules, but this doesn’t make them any less useful. In fact, their flexibility makes them applicable in a broader range of cases.
That flexibility gives the developer a lot of discretion, but it requires the developer to exercise more of their own judgement as well.
Here’s where this applies to the concern you raised that we might be throwing hard won knowledge out the window.
When folks started to write Gang of Four style books for other languages (GoF was originally written for C++ iirc), they needed to change and adapt the patterns. Sometimes they needed to make considerable changes. Sometimes they needed to throw patterns away completely because they didn’t make any sense in the new target language. (I’m thinking of the Ruby one especially.)
This reinforces the idea that patterns aren’t very flexible. It’s really hard to apply them across languages. It’s way harder to apply them across the OOP/FP border.
Principles are much more likely to make that trip successfully. My suspicion is that in the line you quoted from Dave Thomas, he’s talking about something closer to principles than patterns. (But that’s only my suspicion, and I don’t want to put words in Dave’s mouth.)
Also in this respect, Elixir isn’t really new, as you say. Elixir semantics are very close to Erlang’s, and Erlang has been around for decades. Elixir and Erlang are just different from most other paradigms. So this idea that we can readily apply patterns, not principles, from OOP seems really unlikely to me.
?) And I am pretty convinced that the same will happen when I dive into logic programming, may it be classical prolog or miniKanren. Take a look into the wonderful book “Structure and Interpretation of Computer Programs” from Abelson and Sussman on how to implement all these programming concepts in a functional setting.
