I'm looking to collect information on why certain functionality found in Erlang/OTP is usually handled instead by a third party library in people's projects.
This could be bugs, missing functionality, poor interface, performance, etc.
Examples off the top of my head that need expanding on are:
- httpc
- httpd
- http_uri
- reltool
Please comment on this gist with libs and reasons, even if you aren't sure they are accurate or still accurate today.
Unicode is a good example. And we should look at Go for the solution:
Just providing to_upper and to_lower is 99% of the time going to be a mistake. It is a complex area where you need to take care about the details.
@vans163 (RPC) Most applications use the
rpc
module sparingly in which case it is fine. The problem occurs as soon as you use it for every cross-call you have in the system (which you don't have to). You can build your own more efficient variant, or you can avoid even using the module in the first place. The problem is the gotcha: people seerpc
and go "I know RPC! I'll use it!". But if you have apid()
in Erlang you can send it a message, even if it is on a another host.As for @waisbrot's comment:
xmerl
should never have been part of the stdlib. Likewise,jsx
shall not be part of the stdlib. I'd much rather have a small set of "blessed", "maintained" packages onhex.pm
which we use for these kinds of things. Once these things goes into a stdlib, they are set in stone and will move very slowly. The world around them changes, and then you have the same problem as always.jsx
is an excellent example because it makes the trade-off of being written in Erlang, and thus about 10 times slower thanjiffy
which uses a NIF. But using aNIF
has its own set of complexities, so not everyone wants that library. You must be able to pick among several poisons.It also goes for my view on library design: include the things in the stdlib which are impossible to implement as a library (ETS, ...), or are so tightly coupled to the ERTS system that you can't evolve them separately on their own lifecycle.