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:
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 see rpc and go "I know RPC! I'll use it!". But if you have a pid() 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 on hex.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 than jiffy which uses a NIF. But using a NIF 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.
When it comes to HTTP it has never been a top priority to Ericsson. The httpc absolutely still suffers from the problems I described regarding eldap. E.i something half done was contributed and we have to try making it better. We do have some plans for further improvements but alas I can not make any promises, as we also have a problem prioritizing it.
When it comes to httpd our vision is to try to simplify it and make it a small simplistic embedded web server. We do not have the people to make it otherwise. Also there are Ericsson projects that use it this way and are happy that it solves their needs.
Some better calendar module would be great. Current calendar have only basic primitives, but some more high-order library often required to perform date arithmetics, timezone calculations, formatting and parsing. (And I guess everybody hates to type this datetime_to_gregorian_seconds, gregorian_seconds_to_datetime each time).
Humm... I got this dupplicated so I thought I removed one copy but it seems it went away altogether! So here we go again!
@aerosol
This is a symptom of that the OTP team have not had a good enough process for including contributions. I think it is just lately that PR-process has started to work good enough.
In the past it was quite common that prototypes that work well for some use case where included without proper tests, documentation or code reviews. We do have it in our backlog to
make eldap into a proper OTP application, it just has not been prioritized high enough yet. PR are welcome.
I also guess that not everybody are happy with the way how we do configuration. sys.config files and application:get_env sometimes don't fit our needs: config files should be written in erlang syntax; sometimes configs should have some other logical structure, not just <application>.<key>.
Yes, calendar module is a disaster in the user experience sense. It should really be replaced.
JSON's prevalent enough that it feels a surprising not to have a JSON-parsing library built in (like how
xmerlis). I usejsxbecause compilingjiffyhasn't always been a smooth experience.