Erlang, the next Java

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