The most obvious example is thinking in classes and then mixing in behaviour from "magic" modules through inheritance and multiple mixins.
Phoenix for example uses the "use" macros like in my post above to mimic this horrible behaviour. In an erlangish approach you would mainly explicitly import and export functions from clearly specified modules.
If you specify a -behaviour (i know its not a perfect analogy but illustrates the point) that would not magically add extreme amounts of code paths but only force you to export the correct functions for what you try to do.
While “use” resembles mixins, it is a much restricted version of whatever you can do in Ruby thanks to lexical scope, closed modules (via open classes), and immutability.
In practice “use” is closer to Ruby’s refinements, which is something that never caught in Ruby because they were too restricted.
You are right that you don’t see this in Erlang but you don’t see similar high level frameworks in Erlang either. Many don’t care for them but many also find such tools an essential part of their toolkit.
Phoenix for example uses the "use" macros like in my post above to mimic this horrible behaviour. In an erlangish approach you would mainly explicitly import and export functions from clearly specified modules.
If you specify a -behaviour (i know its not a perfect analogy but illustrates the point) that would not magically add extreme amounts of code paths but only force you to export the correct functions for what you try to do.