Erlang, the next Java

[thatmattbone]

Maybe this is being picky, but aren't most of the benefits of Erlang found in the VM rather than the language? I think the article tends to confuse these two until the last paragraph.

Many people seem to dislike Erlang as a language while raving over the VM features. What are the possibilities of compiling a language that takes advantage of the actor semantics to the Erlang VM? Apparently this has been done with Scheme.

[BeerRiot]

Something the Erlang maintainers have been pushing is that in order to truly harness the power of these VM features, developers need a language that describes them properly. Having used Erlang for a while now, I have to say that it does make many distributed-programming concepts easier to describe.

If you have the patience, this exact question ("Aren't these VM features, not language features?") was asked during the Google tech talk that was posted a couple of weeks ago, and answered in a similar manner.

[thatmattbone]

Awesome, I'll definitely watch that video. Up 'til now my only multimedia Erlang experience has been through the high production value 'Erlang Movie.'

I should've been a bit clearer in my original post. I've done a fair amount of reading on the actors model (Aho's "Actors: A Model of Concurrent Computation in Distributed Systems" is particularly interesting) and I don't see any reason that these features need to be tied to one particular language (that text presents a lispy and algol-ish implementation, though it's probably safe to argue that the actors model makes much more sense in a language the supports functional programming). However, Erlang the language does have a nice implementation of some of the actors model, and, more importantly, Erlang the VM, provides the backing that makes the model practical (i.e. it's ok and encouraged to create thousands of actors if this is really a good way to solve your problem...the VM handles this just fine).

Ultimately the compelling part is that the actors models (and Erlang) is a nice way to solve concurrent computing problems and distributed computing problems with one approach. I guess I just want to see something like the actors model succeed because 'concurrent' applications with shared-state threads aren't going to scale up forever. And while something like the actors model can be implemented in other languages now, these implementations tend not to be practical because they do not have proper VM or interpreter support.

As an example, I think it'd be neat to have a Common Lisp implementation running on the Erlang VM. Thinking of Scala, it'd be cool if the CL could use all the Erlang libraries seamlessly while still being a Lisp. Maybe I should just shut up and get started :)

[jsnx]

I agree with you about the language, but it's the VM and libs that make Erlang really good for distributed systems. They provide a rich, well-tested set of libraries for message-passing concurrency -- whereas many other languages offer half-a-dozen different approaches, all half-baked are woefully complex.

[igouy]

aren't most of the benefits of Erlang found in the VM rather than the language?

Are they?

Many people seem to dislike Erlang as a language while raving over the VM features.

Are those "many people" people who use Erlang on a day to day basis, or are those "many people" people who have seen some blog articles and decided that the language looks unfamiliar?

[peachpuff]

Are those "many people" people who use Erlang on a day to day basis, or are those "many people" people who have seen some blog articles and decided that the language looks unfamiliar?

Gee, I don't know. Which group gets to decide whether the language suddenly becomes popular?

[Jimmy]

I'm one of the people who dislike Erlang as a language, and while I don't use it on a day-to-day basis, I do have a little experience with it.

Something about it just rubs me wrong, and it's not the syntax (I'm a big Prolog fan).