I think the first time I hit the mailing list was because I couldn't figure out how erlang can boot up and change its effective user id. (setuid). The reason being it needs to grab a privleged port as root. Well forget that, it has no idea what that means. The recommended way is to use iptables port forwarding. I think thats how couchdb does it (or one of those nosql things)

Logging also didn't seem to fit well with linux. You can manage to write some stuff to syslog, but erlang really prefers its confusing way of logging. See things like this http://www.erlang.org/doc/man/sasl_app.html.

Oh and if you decide to just write data to the error log in the simpliest way possible, like this error_logger:error_msg("An error occurred in ~p~n", [a_module]). Guess what, it doesn't open that log file in append mode, so it wipes it out every time you restart the erlang process. You have to write and install your own error log handler to open the file in append mode.

Want to do some dns lookups? Sounds simple. It starts up a gen_server thread... and starts caching the results! Talk about principle of most surprise. And it doesn't handle mx records. But if you get on the mailing list the guys will tell you there's an undocumented library deep in the distro that will handle this, and probably won't change. So you give up in frustration and just write a port to run dig.

It just went on and on.

You can really tell that erlang evolved to run self sufficient on special hardware and not in a supportive unix environment.

And of course there are the basic language frustrations. What bothered me the most was simply the lack of a 'return'. This meant you couldn't 'short circuit' a function, like "if something then return", and it often resulted in another level of nesting, even for the simpliest stuff. Yes I know that sometimes you could use function pattern matching to factor this out, but not as much as you hope. Having a 'return' statement in erlang is part of a religious war, which I'm not going to fight, but I'm strongly on the having side.

I found some erlang things worked great for my project, like the server and finite state machine 'behaviors', but when I realized the string processing was so slow I just switched to stackless python, wrote it in a fraction of the time, never used it, and ended up keeping the existing perl version :)

You can write a MTA in any language, so its probably not the best fit for erlang. The best fit for erlang would be something that only erlang could do, and just suffer through it ;-)