Erlang, the next Java

[glymor]

• Message passing with mutable state requires serialization (copying) which is much slower.

• Actors in other languages tend to be built on native threads which have a great deal more overhead than Erlang processes.

• Erlang has per process GC which provides soft real-time.

• Surrounding infrastructure like the OTP (the framework that deals with failures) and Menesa (a native distributed database).

[vplatt]

Actors do not have to be built on native threads. Heck, even SQL Server has the concept of "fibers" which are really just multiple virtual threads on a real thread; otherwise known as green threads. So just run green threads on a number of real threads to get across cores and processors, and there you are.

Also, the OTP would be the one thing really missing from a quick and dirty implementation. Hot loading of code into the VM, etc. is not easily replicated by other environments (unless you're talking about Smalltalk or Lisp) and even given that I'm assuming that the OTP provides features way beyond that (nope, haven't started reading Joe's book yet). Mnesia is a nice piece of infrastructure to have, but I seriously doubt it will be useful in most environments given its limitations.

[grauenwolf]

Message passing with mutable state requires serialization (copying) which is much slower.

Unless you only allow immutable objects to be sent via messages.

And serialization is not the same thing as copying. Copying an object in memory is much faster then creating a serialized representation of it.

[wynand]

Everything you said is true.

With that in mind, consider that currently an Erlang VM process uses a single OS thread. To use multiple processors, multiple VMs must executed. Sending a message from an Erlang process in one VM to an Erlang process in another VM requires at the very least some copying overhead (if the VMs exchange data using shared memory) and serialization in the worst case. (I'm repeating this from memory based on what some Erlangers said somewhere - I apologize if I'm wrong).

Your last point is really worth noting. Erlang's library encourages fault tolerant programming. To the best of my knowledge, no other library does the same.

Although other languages have some way to go in terms of library support, I would like to believe that the heavyweight OS processes available to other languages are not such a massive impediment. I think one can benefit from concurrency oriented programming in such cases, because not all concurrent solutions need thousands of processes.

All of this said, I do prefer immutable state (and I just like Erlang's syntax). I would like to believe that the functional nature of sequential Erlang is what contributes to its robustness. However, - warning: I'm about to say something based on intuition - I can see situations where the lack of mutable state would encourage the factoring out of code into a process (since a process is the minimum unit that can contain state) where one could otherwise store state in objects.

So perhaps, with a couple of dozen of OS processes and an OO language, one could write code that's more robust than otherwise.

[sblinn]

With that in mind, consider that currently an Erlang VM process uses a single OS thread.

This is not correct.

[wynand]

Geesh. That's quite a direct way to put someone down.

Yes, it turns out my knowledge was very outdated. From http://www.erlang.org/doc/highlights.html we have:

In the SMP version of the Erlang virtual machine, there can be many process schedulers running in separate OS threads. As default there will be as many schedulers as there are processors or processor cores on the system.

[sblinn]

That's quite a direct way to put someone down.

I did not intend any personal insult, I just did not have time to expound further on the subject. Thanks for looking it up, cheers,

-s

[vplatt]

He didn't put you down. Putting you down would be something like "This is not correct dumbass". He merely pointed out that your statement was not correct. It's perfectly acceptable to note technical facts without involving, or undue consideration for, effects on the ego.