I’m glad this was written. This is one of the mistakes that I see constantly with people new to Erlang and Elixir. People end up trying to use OTP because they hear how awesome it is, but still don’t truly understand how it is meant to be used (I’m sure most, if not all, people go through this phase while learning Erlang and Elixir. I know I did). Like this article says, it ends up with people creating artificial bottlenecks in their systems. I’m sure this has lead some individuals and teams to abandon the BEAM because they just didn’t put the time in to truly understand OTP, thinking they had.

The other most common mistake I see people have with Elixir is the use of the pipe operator (|>). People will try to force the pipe everywhere, even when it shouldn’t be. Something as simple as

def foo(bar) do
  bar |> baz()
end

would be better as

def foo(bar) do
  baz(bar)
end

But then people also try to come up with complex scenarios just to be able to use the pipe. I had seen the following recently

val |> foo() |> bar() |> (fn(a) -> {a} end).() |> Tuple.insert_at(0, :ok)

when

result = val |> foo() |> bar()

{:ok, result}  

is infinitely more clear.

If you had a similar experience with OTP in the past, I would suggest taking another look at the BEAM language of your choice. In my experience of the last 3 - 4 years, the community is very friendly and willing to help with most issues you come across. I think the BEAM has great things to offer a number of projects.