yes indeed I'm increasingly using couchdb, planning on picking up erlang and it would be useful to avoid the mailing list if you can pass info along...
This was a few years ago, so my memory is foggy and things might have changed, but I remember how uncomfortable erlang felt in a unix environment. I might have felt the same way about java, since its also sandboxy.
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 ;-)
AFAIK it was written as the research, not to run at any specialized hardware, then "sold" as being able to run the phone switch, but it needed a "big iron" computer attached to it just to drive that switch (!) -- it was that slow. And AFAIK it's still very slow. Up to quite recently it wasn't even able to use more cores.
Where did you get all that from? Erlang was never intended for research but as a tool for writing real switch applications. Yes, the original Prolog interpreter was slow, but that has not been used for almost 20 yrs. We never had "big iron" computers to play with, and never really needed them either as the system has been efficient enough to run on computers that were cost effective for the actual applications. The implementations have always been optimised for applications that are highly concurrent and extremely fault-tolerant, like telephone switches. Yes, it was a bit slow in being able to use more cores but that was because Ericsson, who still maintains the BEAM implementation, did not have need of it. Now, it will take as many cores as you can throw at it, and be able to use them if you have written a truly concurrent application (Amdahl's law). Transparently too.
Ericsson could have had a need for multicore already back in 1997, when the first SMP Erlang prototype was written, but the space and power budgets for the processor boards made it impossible to get any matching hardware for it. SMP in those days was not multicore, but several CPUs. It was only usable in servers - not in embedded systems.
I remember reading "Erlang - A survey of the language and its industrial applications" (Joe Armstrong - in INAP'96)
Now I've checked again, so let me summarize:
It started to spread "outside the lab" in 1987. In 1995 there were three commercial applications: network simulator, mobility server and distributed resource controller. First is a simulator, not running on the specialized hardware, the third was running on "a network of Windows NT machines." The second: "acts as a call control system when linked to the PBX"
OK, the second was running on the additional SPARC-based machine, not big iron, but AFAIK certainly more powerful than the PC's of that time.
So I don't see anything that was targeting really "specialized hardware" particularly not what we'd think as embedded (less power consumption, slower processors than the PC CPU's). It was a research project, and it had traditionally performance problems.
Even today, after so many years, when you compare Erlang HiPe (Hi Perf, you can imagine others then!) with something higher than C, let's then say Lua JIT it's easy to see which one is faster:
