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.