@Steve V. Why do you think that the message passing feature has to be hardcoded into the language?

If we can get message passing implementing in Scala as a library, I think that could be an advantage over something that is hardcoded into the language.

Comparing an implementation to a turing-complete formalism is strange. Just because Erlang has syntactic support for message passing doesn’t mean it is an embodiment of pi. Remote object refs perform the same function as erlang pids, FWIW.

Also, pi-calculus is about concurrency, not parallelism.

On a slightly related note, here’s Wil van der Aalst on why he thinks the term “pi-calculus” is thrown around a bit too liberally.
http://is.tm.tue.nl/staff/wvdaalst/publications/p257.pdf

As yourself, I have only toyed with STM and never used it on real projects, but I feel they are conceptually higher-level than other concurrency mechanisms and hence maybe easier to work with. Moreover, the fact that, at least in Haskell, you can compose STM computations together while keeping its properties is really interesting.

Of course, this is only a ‘feeling’, having dealt mostly with threads and message-passing style concurrency ni my past programming experience.

Merry christmas,
Arnaud

STM is a mechanism to share state between processes and fits into the first category.

I haven’t tried STM in a real world project but would be eager to, perhaps 2009 I find a suitable project.

There have been some articles along the lines of STM not scaling though.

http://queue.acm.org/detail.cfm?id=1454466

STM based transactions do not exchange data per se, running in isolation, yet by virtue of retry and conditional, they can be synchronized with one another.

Regards,
Arnaud

PS: and don’t feed the troll ;-)

“The reason I brought up the Windows system was supposed to be a counterexample, but you were too busy telling me I’d missed the point to realize that you were missing the point of said counterexample.”

I’ve read it again and again, but I can’t see how this is a counter example.

Windows process do share state, threads don’t. What am I missing? I’m sorry your responses are to vague to my level of understanding. There might be hints but I’m too stupid to see them.

On the other side the comments just look like name dropping,

“Parallel channels, identified channels, proxying, masquerading, voluntary yielding, continuations;”

It would me nice to elaborate one point instead. With

“can or cannot message”

it seems to me that you change my words all the time:

“* First: Need to share data
* Second: No need to share data (or “not to share in real time”)”

Instead of providing me with some key words to find concurrency examples on your site your only comment is:

“Indeed.”

Thanks for your comments, they might have helped some readers. They haven’t helped me.

We both have different views on the topic. I want to share knowledge, you want to prove I’m stupid. Well I am. Merry xmas.

I think you might have missed the point again. There are different types of concurrency, one where the parallel running processes/actors/objects/things share information and one where they don’t exchange information. If you know more, you could fill me in.

I tried to; you were too busy feeling correct to look into the hints you were given. Windows parallelism fits neither model. Windows processes do not share memory (at least not without significant contrarian gymnastics, but the same can be said of every pure implementation the average programmer can name); Windows threads do. The reason I brought up the Windows system was supposed to be a counterexample, but you were too busy telling me I’d missed the point to realize that you were missing the point of said counterexample.

I realize it’s very comfortable to repeat what you’ve been told, but try this again. There’s more to the world than “processes can communicate” and “processes can’t communicate”. Parallel channels, identified channels, proxying, masquerading, voluntary yielding, continuations; there’re all sorts of approaches out there which do not map to your very black and white world, and the fact that the world’s dominant parallelism model is one of them should be something of a red flag to you.

It really isn’t as cut and dried as “can or cannot message”, even if you want it to be, and even if you don’t know about the alternatives. I wasn’t at all cryptic about my counterexample; you should have read up on it before assuming you were correct.

From a first look I can’t find relevant tutorials to concurrency using the search on both pages. Perhaps I don’t use the right key words.

Indeed.

http://lamp.epfl.ch/~cremet/publications/pilib.pdf

This was a legitimate mistake to make. That isn’t honestly the pi calculus, even though its authors present it as such. Many of the most important guarantees of the Pi Calculus derive from isolation, which cannot be provided on the Java virtual machine for reasons that I’m sure you’ll ask me to explain at length instead of just researching, since this is apparently my tutorial and my blog, and since you feel comfortable refuting essentially any comment by saying “you haven’t written a book hard enough, therefore you are wrong.”

This may help elucidate the point.

http://www.cs.cmu.edu/~wing/publications/Wing02a.pdf

Frankly, your “as John wasn’t kind enough” comment reeks of contempt; if you had been less standoffish about the help you were offered in the first place, you might have received more. As stands you’ve got a last read and a disinterested goodbye.

http://lamp.epfl.ch/~cremet/publications/pilib.pdf

A library for the pi calculus. As a bonus: Implemented in Scala.

I think you might have missed the point again. There are different types of concurrency, one where the parallel running processes/actors/objects/things share information and one where they don’t exchange information. If you know more, you could fill me in.

The other thing is mechanisms to solve the concurrency problems that arise from the first and second kind of concurrency.

But solutions or mechanisms or models and concurrency types are different things.

“I have been. For a long time. http://sc.tri-bit.com/ and http://fullof.bs/ are both me. I’ve written dozens of complete tutorials on half a dozen languages and serious topics.”

From a first look I can’t find relevant tutorials to concurrency using the search on both pages. Perhaps I don’t use the right key words.

@J: SomnifugiJMS is nice, especially if you already know JMS (used if for an intra application bus for Swing applications). I also liked Werx as a bus system – but the open source project is discontinued (It had a nice hierarchy system for messages an was fast).

If you’re interested in concurrency you need to read the Doug Lea book “Java Concurrency in Practice”.

Other than that if you need high performance concurreny you best use:

- Erlang (buy the Erlang book)
- If you have Java knowledge then it would be good to look into the Scala implementations of actors and OTP.
- If you need Erlang concurrency in Java you could take a look at Kilim

http://codemonkeyism.com/archives/2008/06/21/interesting-picture-benchmarking-erlang-versus-java-concurrency/

I’m not sure how Actors Guild performs, I need to look into that

http://actorsguildframework.org/

Write your own implementation :-) What people can learn from Erlang is the inbox model (and thinking in supervisors and restarting processes) and take it into the language of their choice.

Coming back to the envy thing. I’ve never understood the concept. If I am envy, why shouldn’t I change to another language? Wouldn’t that be the best thing to do? Staying with one programming language and being envy about another doesn’t make sense to me.

Of course it is defensive that was the goal. There have been dozens sof blogs posts 2008 from people using Erlang with no clue about what other people do.

“[...] them just parrot what they have read in other blogs.”

About Java? Well queues, ESBs, Fork/Join, MapReduce are concepts, not primarily language features. And some Erlang developers seem to forget that message passing, supervisor hierarchies et al are concepts too.

“Message passing is message passing. Is the fact that message passing in one language is comparable to message passing in another language enough to declare that “there isn’t as much difference between concurrency in different languages as people want you to believe there is!”

Yes.

I know it makes Erlang not that wonder language some people think it is. I’m sorry for that.

I have been. For a long time. http://sc.tri-bit.com/ and http://fullof.bs/ are both me. I’ve written dozens of complete tutorials on half a dozen languages and serious topics.

Before you get smug about what other people haven’t done, be sure that they haven’t done it.

“It’d be nice if people saying “there are only N kinds” knew what kinds there were.”

Update: Compare this to “There are mainly two different types of concurrency”. I let the reader find the difference as an exercise.

Should it be the case that these were the main two, you might have a point. However, given that neither of the mechanisms you describe adequately explain the Windows model of threads and ropes inside processes, meaning that you’ve missed something like nine tenths of the real world market, you’re really only lampooning yourself by here.

Yes there are similarities between message based asynchronous architectures and Actor-like systems, but they smell different. A while back I was looking at the JCSP library that puts PI-calculus primitives into Java, it did not look like many of the things you mentioned in Java, though SomnifugiJMS looks interesting as an alternate approach.

I hope you post a followup. I look forward to learning more.

“I’ve been comparing communicating with immutable messages over queues to Erlang, and to me this looks comparable (scheduler and OTP aside).”

But why is that comparison useful? Message passing is message passing. Is the fact that message passing in one language is comparable to message passing in another language enough to declare that “there isn’t as much difference between concurrency in different languages as people want you to believe there is!” Of course not. And that’s the problem I have with this piece — it glosses over way too many details and as a result reaches conclusions that are inaccurate and unsound.

As this is only a blog post and the Doug book is several hundreds of pages long (and the concurrency chapter in the Erlang book on my dessk is much longer than the post), obviously the post is not complete.

It would be nice if you would fill in the gaps and write a post on your own for all of us to learn. Thanks.

“It’d be nice if people saying “there are only N kinds” knew what kinds there were.”

Update: Compare this to “There are mainly two different types of concurrency”. I let the reader find the difference as an exercise.

“[...] concurrency primitives are therefore really no different than those of language Y is way off the mark.”

Am I mixing message passing with threads? I don’t think so. I’ve been comparing communicating with immutable messages over queues to Erlang, and to me this looks comparable (scheduler and OTP aside).

It’d be nice if people saying “there are only N kinds” knew what kinds there were.

Yes, if you stand back far enough, you start to see common concurrency patterns in a variety of different technologies. That’s a no-brainer; there are only so many ways to do this sort of stuff. But to then draw the conclusion that language X concurrency primitives are therefore really no different than those of language Y is way off the mark. You’re incorrectly mixing very, very different levels of abstraction.