[yumaikas]

They are fairly generalizable, to a point.

The thing about Erlang behaviors is that they rely on several other pieces of Erlang to work well.

One big one is being able to be notified when another process goes down, or is aborted.

The other big one is being able to reason about state in the face of such failure.

Erlang decided to go with immutable data structures, shared nothing processes, and the OTP behaviors generally expect you to decompose the behavior of the various bits into functions that represent a single atomic step.

The more of those properties that you don't share with Erlang, the harder it will be to adopt OTP style semantics in your system.

[throwawaymaths]

The other thing about behaviours is... Especially if you have a synchronous API, you can mock it with a stateful system, for example calling out to a GenServer or calling over the network. This is why GenServer.call doesn't emit an error tuple; an network or interprocess error by default is considered to be unrecoverable. In most other systems you'll fumble around with colored functions transitioning between a sync system or async call, or, have to do annoying error handling, or even worse stack unwinding with an exception or get stuck in a panic.

In Erlang, a sync API behavior can safely have a failable async implementation, and that is powerful