I do think the analogy is wrong, here. I don't think OTP tools constitute programming patterns at all–they're a fault-tolerant framework that builds on the BEAM VM's concurrency primitives and other language features.
The OTP tools, in their implementation, may employ different programming patterns, and as a framework they limit the patterns you can use with them because they decide how you interface with them. OTP Behaviours are just one pattern to implement the definition of an interface, you can do this different ways (as Protocol does). You can re-implement OTP tools using those primitives, a custom interfacing mechanism, and different programming patterns if you want to get different results, if you want.
There is a "pattern" for this–it's called syntactic sugar. The OTP framework is bundled with the language, so one could conceivably extend the language with custom syntax for hooking into OTP, or even your own custom concurrency tools. There are three ways in Elixir that you could create elegant hooks into them:
- Parser level: customize the tokenizer and parser with new syntax and define new semantics for them, possibly by extending the list of language operators
- Compiler level: create inlined functions and macros that do what you want, perhaps around overriden or custom operators
- Runtime level: just use normal functions and possibly operators like this guide demonstrates
You'll notice Elixir does do this already! In particular, only through the latter two mechanisms, without any custom operators. I think is a wise choice because it keeps parsing separate from syntax and semantics, and leaves the operator field wide open for custom use-cases, like your envisioned concurrency toolbelt.
- Behaviour, Supervisors, GenServer, and GenEvent are macro-wrappers around existing OTP tools (you don't have to use them to define OTP-compatible modules, and could write your own if you wanted!)
- Tasks and Agents are higher-level abstractions around existing OTP tools
- GenStage and Registry are completely new, non-OTP concurrency tools responding to some pain points in GenEvent and gproc, respectively
With that background, to respond to your post point-by-point...
That's because prefers to reinvent his own concurrency tools and behaviours from language primitives, or just use the primitives. If he packaged and published his tooling, you'd have just another OTP-like toolbelt in the ecosystem, which would be great. But the core appeal of OTP is that it's done and battle-tested for you.
I think some tools are built to assuage language weaknesses. But some tools, like OTP, are built to make using the language's strengths easier. I also think Lisp's core language weakness is that it doesn't have many standard tools built in, so its core language strength (metaprogramming) is used heavily to compensate. "programming patterns are bad" seems like a silly way to defend a core language-tradeoff that LISP made.
That would make sense if we wanted Elixir to be a LISP-world. Instead, Elixir's made some trade-offs in it's core library (like, for instance, having one) so that developers can be more productive out of the box, without navigating a package manager or auditing third-party code to decide how to do Enumerables, for example. Elixir inherits the OTP tools as well as adding its own.
Where it takes a leap beyond Erlang in it's design, is that it's hackable with macros to let you do anything you want to, within its parser and lexer limitations, if you're willing to write the macros. This is how the pipeline operator, conditionals, and tools like
with work–they're totally new syntax and semantics, fitting within the lexer. You could build your own macro-powered concurrency tools that feel as native as those macros.
As mentioned, Elixir has already has done this, although purely on a semantic level. However, nothing's stopping you from a very interesting investigation into pairing your own concurrency tools, or pairing existing OTP semantics, with custom syntax. Just learn your way around macros and color in-between the lines that the lexer gives you. If you have some ideas in this front, I'd love to see your experimentation!