Somehow I don't think rolling their eyes at developers discovering a need for what they have to offer will do the Erlang community any good.
If they sincerely believe that Erlang offers a superior alternative to Node for what the influx of new Node developers need, then they should be looking to provide resources to help these devs "graduate" to erlang.
Not once have I seen a blog post saying "Like Node.js? Then you're going to love Erlang! Let me show you why it's better, with some snippets to compare and contrast."
Not once have I seen a blog post saying "Like Node.js? Then you're going to love Erlang! Let me show you why it's better, with some snippets to compare and contrast."
Given the fact that there already exist bridges that can take javascript snippets and run them in sub-processes within erlang I am really surprised that no one has bothered to do a "enode" system that just provides a node-like api for the callouts to the javascript processes.
couchdb can only run javascript functions on json objects, and really only to transform those objects into other objects. last i checked, it has no way of interacting with the erlang node it's hosted on.
I like different languages but Erlang is like Lisp in that it has yet to really grab me. The difference being, Lisp has far better odds of grabbing me. As far as I can tell, Erlang's advantages can be cloned elsewhere in more pleasant to work with languages.
Could you list what you consider to be Erlang's advantages? Most of the ones that I can think of off the top of my head fall into the range of "possible to clone, but would take a huge amount of engineering effort" (e.g. OTP), or alternatively "a culture issue" (e.g. "let it crash", and the language's completely obsessive focus on application stability, both of which are pretty much diametrically opposed to the common language philosophies today).
I was thinking primarily of "let it crash" and "message passing". They don't seem particularly tied to the language. I'm not familiar enough with the OTP to comment.
I must have missed the current common language "philosophies", at least what concerns their opposition to focus on stability ... what are these? Can I avoid them?
C is not a language optimized for stability. The possibility for segfaults, buffer overflows, etc. and the lack of a sensible mechanism for handling them other than "write the program correctly" demonstrate this. It is, essentially, a language optimized for writing Unix.
Shell is not a language optimized for stability. It is optimized for interactive use, above all else - it's not even a very good scripting language, even though it's historically been used that way an awful lot.
The primary focus of Java (at the time of it's creation) was "write once, run anywhere". The primary focus of Java (now) is "languages that compile to JVM bytecode are nifty - plus, we have C-like syntax but are a high-level language".
The primary focus of Erlang, before and above anything else, is program stability. OTP exists to increase stability. "Let it crash" exists to increase stability. Parallelism and message passing are in the language not because they're neat, but because (if they are used at all sensibly) they will increase stability.
Put that way your point is more clear. You compare with languages from the last 40 years, I took some issue with "current".
Still I cannot see why this is a cultural issue that keeps developers away. Missing things like good string-libs, or ",;." syntax hassles, ok. But stability-features?
The point you address for C is , in a way, also valid for Erlang. It's your program which has to be stable, the language just offer you supervisors and independent processes. "Write it correctly" is the only way to achieve that goal, Erlang does not help you with that. Could be that messing up an OTP behaviour is as easy as dereferencing a null pointer... (disclaimer: I'm no Erlang developer)
Oh, I agree. Every time someone advocates Erlang they mention how it was used to build super-reliable telecoms and they start mentioning three-letter acronyms and immediately everyone's eyes glaze over. It just isn't sexy like node (yet?).
There are always Efene and Reia if you want sexy things. (However, I find it somehow disturbing that there are almost no documentation on Reia beyond the examples on its site's start page.)
One could compare Node.js to Twisted, Tornado or EventMachine. However, comparing Erlang to Node.js is somehow weird as they have different paradigms — Erlang is highly-concurrent with its "green" processes, while Node is single-process single-thread with "asynchronous" paradigm.
(However, there are some aspects, that could be compared. Erlang has "let it crash" motto, while in Node.js one has to be careful with any exceptions. Erlang is distributed and Node.js has no notion of processes.)
