

Erlang is slow: and other rubbish - l0gicpath
https://kivikakk.ee/2013/05/20/erlang_is_slow.html

======
memracom
This article is actually a great example of how to logically approach a
problem, decompose it into its components and address each one in turn. In
this case the author is applying the process to architectural decisions but
the process is just as applicable to debugging and to root cause analysis of
system/network problems.

And as usual, when you follow the rigorous process without jumping to
conclusions, you can come up with better or easier to implement solutions. In
this case, the issue says nothing about Erlang or Python but it says a lot
about the choice of serialization methods for a network protocol and the need
to choose an appropriate library that meets the use case, i.e. how fast do YOU
need it to be. Some applications do not need fast, they need simple. But for
the application being discussed, network performance was very important and
they made mistakes by not paying attention to that. And as the author points
out, the solution that they chose might have made things better, but was less
than optimal. There were faster libraries that they could have used, and of
course, they might have done even better with a binary protocol.

------
wilg
I was going to get on your case about how referring to the author of the
original post as "the intern" constantly seemed dismissive, but I actually
can't find byline on the original post. That's crazy. There should absolutely
be a byline, especially since it's written in the first person.

