Bill de hÓra writes...
Both JRuby and Jython have experienced stop start development.
And then goes into several interesting directions. (BTW, the original Erlang book is good, but not essential for adopting Erlang. Instead start with
Erlang in Real Time which is online and more in-depth. Everything else you need is on the erlang site, including the mail lists.)
Anyway my thought is that running multiple languages on the JVM or CLR is beneficial simply because there are no *really* good inter-language communication mechanisms. Being in the same OS process is useful but certainly there are times when that is undesirable for security and reliability reasons.
Given the oncoming multi-core low end systems, the oncoming many-core high end systems, and the realization that "SOA" in its best possible interpretation is just "reality" for tomorrow's programmers (cf. "Notes on Postmodern Programming") we need to get over this "use my OS/VM/language" / "no, use *my* OS/VM/language" parade asap.
Erlang may never be popular regardless of the books available or not. (Then again with ejabberd, Erlang *may*... er, forget it. Jabber will more likely be the inter-language communication mechanism I claim we're missing.) But just as Lisp got data right, and Smalltalk got objects right, Erlang got processes right.
Sooner or later your language and runtime will too. And the sooner the better because I cannot count on anyone porting my language to your runtime, and I sure don't have any incentive to do so myself.
Meanwhile rather than try to program all of the latest Ruby or Python in the JVM or in the CLR, I am wondering whether we need to expose Java and C# libraries via their own processes connected to a simple communication mechanism with a simple, reflection-based interpreter on the receiving end.
Hey, JVM, just sit there and do what I tell you. I don't need that to be more than the current implementation of Jython or (the upcoming 1.0 release of) IronPython. Or take your pick, maybe Javascript is the lingua franca via Rhino and... er, dotnet does have a Javascript interpreter, right?
If I ship my application to you as a, say, a VMWare player and image running the OS of my choice, pared down to what my application needs, plus a few OS processes running on that image, each implemented in the language of choice for that process, plus some inter-communication between them, and all of them going out to the real world as desired, then... would I be happy with that kind of Gordian Knot post-modernism?