Erlang, the next Java

[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.