Notes from a Concurrency-Oriented Junkie

Joe Armstrong is at it again in this interesting Erlang-General list discussion, providing a witty yet mind-expanding approach to Erlang program design in Erlang's unique Concurrency Oriented (CO) paradigm:

I always tell people this:

  1. Identify the concurrency in your problem. Give the processes names.
  2. Identify the message channels - give these names.
  3. Write down all the messages that are seen on a channel, give these names

In doing this you have to chose a "granularity of concurrency" that is appropriate for your problem.

If you are modelling crowds then one process per person would be appropriate, you would not model a person as 10^26 molecules with one molecule per processes.

And also

In Concurrency Oriented (CO) programming you concentrate on the concurrency and the messages between the processes. There is no sharing of data.

An Erlang should be thought of thousands of little black boxes all doing things in parallel - these black boxes can send and receive messages. Black boxes can detect errors in other black boxes - that's all.

Ripped from the Erlang List

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Wasn't it exactly what he said..

In his invited speech at Lightweight Languages 2002?

Aaargh. That number of threads argument again ...

While I really like Erlang and appreciate much of Joe's observations, I have to part ways when it comes to comparing numbers of threads. It's a ridiculuous metric. So what if a Java environment doesn't support 100,000 threads? A friend of mine compared the BEA/Weblogic server (java-based, uses async i/o) against Yaws and yaws comes in at a third of the performance. Compare throughput, not number of persistent connections. It doesn't do you any good to have tens of thousands of connections if you can't really serve them effectively.

But I like Erlang.

Missed the point

Joe was just saying that Java is not a CO language. Which it is not. In a CO language, a new process is created as a way to structure your program, not as a way to deal with throughput or any other performance issues.

I think this quote made his point about this:

Suppose I had invented a new OO language and said to people:

"Don't use more that 2500 objects, because if you do the system won't work"

throughput

IIRC correctly Yaws was optimized for dynamic content creation, so I'm wondering in your friend's comparison, was this .yaws files against some servlets or was it static html pages?

Anyway I would be interested in seeing the metrics of this comparison, I don't have a BEA/Weblogic server to compare it with so I don't know.

I suppose the most interesting thing was how does throughput decrease with the increase in processes, it probably does help to have tens of thousands of connections if you serve them at the same rate as you do several hundred, even if that rate is sort of poor in comparison to other servers.