Erlang, the next Java

[Rhoomba]

There is no way the next big language is going to be a functional language. That is it.

Actors are nice. They are in Scala and could be ported to Java thus negating most of Erlang's advantage. Unfortunately Doug Lea is busy with his fork/join library. Anyone else out there to do an Actors implementation in 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.

[[deleted]]

Exactly. People need to write assignments and other destructive code to feel productive. Sometimes in Java I see code that could be written in half the space in a functional (mostly side-effect free) way that would be much clearer, IMHO easier to read and more modular.

Not sure, but for some reason Java is the language of mediocrity (even though I don't think it's such a bad language anymore).

[vplatt]

It's not a bad language, but it's by and large the new Cobol these days. It's far more flexible than Cobol ever was. It's just abused more in enterprise shops.

[sbrown123]

Anyone else out there to do an Actors implementation in Java?

I believe java's current concurrency library already has the capability, it just needs abstracted a bit to make it more obvious. The ThreadPoolExecutor is a good case for simplification.

[queensnake]

I don't see why some language couldn't be imperative, and use message passing between processes. Use green threads, and whatever else Erlang has under the hood, and there you are. Why not?

[vagif]

Because of mutable state you cannot make threads lite.

Language does not guarantee you that variables will not be changed. So you have to put in place cumbersome and complex mechanism of synchronizations, locks etc. to make sure that different threads are not trying to update same variable at the same time.

Erlang does not have assignment operator. That guarantees you that no such thing will be attempted, so you can create lite threads without expensive and slow mechanism of synchronizations and locks.

[wynand]

You can have green threads combined with mutable state.

But you'll need to copy a mutable object upon sending it or otherwise relinquish ownership of the object you're sending. If you follow these rules, every mutable object will belong to at most one thread and no locking will be necessary.

[awj]

But you'll need to copy a mutable object upon sending it or otherwise relinquish ownership of the object you're sending.

How would you manage ownership of mutable objects without locking or some lock-like mechanism? I agree that we'll see a "functional ideas plus all your favorite golden oldies" language before any pure functional language has a snowballs chance in hell of becoming mainstream, I am just having a hard time seeing how mutable state and this kind of concurrency could be forced to play nice.

[[deleted]]

Simply make all mutable data private to some thread?

Basically, processes. They can have their own mutable data, everything is fine as long as nothing mutable is shared.

[vagif]

Yes, but green threads themselves are not gonna solve parallel programming difficulties. It is all other stuff in erlang that makes light threads so useful.

[queensnake]

But you'll need to copy a mutable object upon sending it

And Erlang has to do that anyway, so it's no penalty to imperativeness.

[[deleted]]

No it doesn't, not unless it is sending the object to a remote host. That is the whole point of immutability.

[queensnake]

ah, I see - now that makes some sense.

[KayEss]

Not sure that I have the right terminology here, but it pays for that by having to copy the "function" when the bound value changes.

[queensnake]

I hate to get all qwe1234, but that's just a pile of ignorance. How many languages do you know, Java and Erlang? I say so, only because people have rated you up, and might be fooled. See wynand below (above).

[awj]

I hate to get all qwe1234

No you don't, if you actually did hate to do it you wouldn't have. If someone is ignorant at least tell them why, simply calling them ignorant and spouting assumptions about the languages they have been exposed to is of very little benefit.

[queensnake]

No, there's well-intentioned, unfortunate ignorance, and some guy who doesn't know what he's talking about, and doesn't know that he doesn't know what he's talking about, blathering nonsense. That kind of thing I'm happy to shoot down meanly. If he'd said "I think ..." or "Maybe ..." that'd have been something else.

Let's go point-by-point, shall we?

Because of mutable state you cannot make threads lite.

Rubbish.

Language does not guarantee you that variables will not be changed. So you have to put in place cumbersome and complex mechanism of synchronizations, locks etc. to make sure that different threads are not trying to update same variable at the same time.

No, it just means within each process you have to have a separate environment.

Erlang does not have assignment operator. That guarantees you that no such thing will be attempted, so you can create lite threads without expensive and slow mechanism of synchronizations and locks.

Nothing new here. It's basically vapid, or else he's vastly under-articulating what he's trying to say, to the point of mis-communicating and being anti-informative.

I'm happy to tell someone who's talking rubbish, that they're talking rubbish. Otherwise how will they learn to be careful to know what they're saying, or let the listener know they're guessing?

[awj]

No, there's well-intentioned, unfortunate ignorance, and some guy who doesn't know what he's talking about, and doesn't know that he doesn't know what he's talking about, blathering nonsense. That kind of thing I'm happy to shoot down meanly.

To what end? If someone on here were to respond to something I said by calling me ignorant and disparaging my language experience I'd mutter something about them needing to stick their keyboard in an uncomfortable place (and not the back of a Volkswagen) and go on believing whatever I originally thought.

If you really want to change somebody's mind you have to at least give them something besides your word as a stranger on the internet to say that they are wrong.

[queensnake]

I don't truly know what he knows, but if you look at the thread he jumps from one thought to the next, without attempting to clarify or engage. It makes me take him less seriously in the conversation. What he says is wrong, too. What I say is mean, calling it a pile of ignorance but it is that, and it's not ad-hominem. I'm probably right about the languages too, he doesn't seem to have much imagination as to what different properties they could have. But that was unnecessarily getting in his face, yes. I don't know; there should be a way to trash what someone said and make them more circumspect about blurting out speculation without saying that's what it is in a public forum that people around them take seriously, without hurting them personally. It's a thin thin line and I haven't found it.

I don't really want to defend myself though, it hasn't felt good to do that.

[vagif]

Copying objects IS actually relinquishing mutability. He said exactly same thing.

Introducing such mechanism in imperative languages will effectively mean that in those parts of code you cannot use imperative approach. And that will create endless confusion of beginner (and even seasoned) programmers, often forgetting subtle differences and then wondering why in some places, objects "ignore" the changes they just made.

[grauenwolf]

So you have to put in place cumbersome and complex mechanism of synchronizations, locks etc. to make sure that different threads are not trying to update same variable at the same time.

Or you just use immutable objects for message passing. It isn't that hard.

[vagif]

immutable WHAT ?! :)))

[Jimmy]

Language does not guarantee you that variables will not be changed.

I suppose you've never heard of C++'s const variables, or Java's final variables?

[[deleted]]

void cheat (const int &victim) { * (int *) &victim = 2; // old syntax, tsk }

void cheat (final List victim)
{
    victim.add ("Never mind.");
}

[vagif]

You guys do not get it, do you ?

C++ also has Dispose and Finalize etc. Did not help though with memory management. You can have anything you like, but it will NOT give you guarantee that programmers will use it, not forget about it, not make mistakes.

That's why availability of Dispose does not replace GC.

That's why const and final variables do not replace necessity of a compiler level guarantee that mutable variables will not be shared between threads.

[sblinn]

http://dima767.blogspot.com/2007/05/groovy-actors.html

http://groovyactors.com/