The behaviour/impl module and separate implementation approach is used by the new Elixir Telemetry library.

I know it’s over a year later, but I just posted an in-depth article covering the layering and swapping mechanisms I gave an overview of in this talk.

I‘ve not had a look at the repo yet, but it‘s probably created by driving the point of the talk all the way to make a point.

On the other hand having clear interfaces is something, which is by no means inherently OO. Interfaces are something your code has even if they‘re not written out somewhere explicitly. At the least you should have it as soon as there are multiple implementations, which can be switched out (and as @josevalim argued when creating Mox, this stands also if a second implementation is just used for testing). This was one point in the talk, that it makes testing easier. But I‘m with you that it‘s quite a bit of ceremony if there‘s only one implementation. It just makes is super clear, which functions are meant to be public interface vs. what is implementation detail. In bigger projects, this might otherwise not be as clear.

Naming errors is imo a good thing like anywhere else in programming, especially for the common cases, which are the ones one has to deal with all the time. It could‘ve been an atom instead of an exception struct, but the latter has the ability to later be enhanced with metadata, while with a plain atom to start with the interface would probably need to change in a backwards incompatible way.

I really liked the talk! It’s basically advocating the use of the Hexagonal Architecture as a way of tackling growing complexity. Just as any pattern, Hexagonal Architecture has pros and cons. The cons are: more abstractions and indirection. It’s up to the developer to decide if the pros outweigh the cons.

Functional programming does not solve complexity on it’s own. I’m working on a Rails app with a god-class - I can clearly see how one could translate this line-by-line into the Elixir land and cause the same pains. Really, there’s no such thing as an anti-pattern: if you’re hacking a throwaway prototype, then cramming business rules into controllers is fine in my books. I guess most web apps would be fine with the “defaults”, i.e. Ecto leaking into the controllers. But that’s not always the case, especially with growing complexity.

I am having mixed feelings about this, the examples in repository (https://github.com/aaronrenner/crowdfundr) even define some very common cases like user entering an email that is already used as an exception (Crowdfundr.EmailAlreadyRegisteredError) and then use that in {:error, exception} tuple.

I am just learning Elixir but I have went through some materials already and I must say this approach looks totally foreign to me. I would even say that it looks like a total oposite of why I turned to Elixir in the first place. The Behaviour/Impl/DefaultImpl thing reminds me too much of the “interface with single implementation” ceremony that used to be common in some OO languages.

What do you think? I would love to hear what others have to say.