Home » forums » LtU Forum

Cω vs. Erlang?

I know there was Cω topic before. But the discussion really had more to do with Xen (XML, DB integration) than the Polyphonic C# concurrency part. I'm an Erlang newbie myself, but I already can see that asynchronous communication is the common thread to both languages and this approach is going to be big - can be used from embedded system to biz process orchestration.

Looking at the Santa Claus sample, Cω code seems to be quite compact and the syntax extension to C# is minimal. However process/thread creation is implicit, and it seems to be a little more difficult to reason. I would imagine a solution in Erlang clearer, but maybe longer.

Any thoughts/pointers on the pros and cons of different concurrency approaches? We really should have a "great concurrency shootout".

By bzhou at 2004-08-13 17:43 | LtU Forum | previous forum topic | next forum topic | other blogs | 8188 reads

Comment viewing options

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

Add Oz

bzhou: Any thoughts/pointers on the pros and cons of different concurrency approaches? We really should have a "great concurrency shootout".

I agree wholeheartedly, and would also like to point out that Concepts, Techniques, and Models of Computer Programming includes "The broadest presentation of practical concurrent programming available anywhere. One third of the book is devoted to concurrent programming. All important paradigms are presented, including the three most useful ones: declarative (dataflow) concurrency, message-passing concurrency, and shared-state concurrency." It's absolutely the best coverage I've seen anywhere, period.

By Paul Snively at Fri, 2004-08-13 18:20 | login or register to post comments

Discussed briefly a while back

In Modern Concurrency Abstractions for C#. Not done much with it since that point in time, but the concern was the amount of overhead possible in OO framework. Erlang has very lightweight threads that incur very little expense. Not sure if Cω can spin them inexpensively.

By Chris Rathman at Fri, 2004-08-13 18:28 | login or register to post comments

Erlang

Erlang's big pros are that it's good for writing "crash-only software" and that most code gets to completely ignore concurrency. This it has in common with Unix: processes have their own private world (Emacs isn't sharing objects and variables with gcc and Mozilla) and you get incredibly powerful invariants about process termination (freeing of memory, closing of files, termination of helpers, inability to corrupt other processes). There's an excellent discussion of this stuff in The Art of Unix Programming.

I think that the most important problem for Java-like languages to solve is having too much to synchronize (a whole world of mutable objects) and no good way to divide it into pieces that can be considered in isolation. I don't understand if Polyphonic C# addresses this problem in context.

By Luke Gorrie at Fri, 2004-08-13 20:08 | login or register to post comments

Ada

Ada tasks communicate synchronously, but I think that more people interested in concurrency should check the Ada concurrency model. It's one of the more widely used programming language based models.

Here's one discussion.

By Ehud Lamm at Fri, 2004-08-13 21:00 | login or register to post comments

ATC

If we are suddenly discussing asynchronous language features again, I think this paper (on Asynchronous Transfer of Control features) is still worth checking out.

By Ehud Lamm at Fri, 2004-08-13 21:22 | login or register to post comments

E Machine

And this one, cited previously.

The E machine proposes a paradigm shift in real-time programming: it permits the programmer to think exclusively in terms of environment time ("reactivity"), and shifts the burden of reconciliation with platform time to the compiler ("schedulability"). This paradigm shift is in line with the steady move towards higher-level programming abstractions. In fact, the E machine treats platform time as a resource in the way in which most high-level languages treat memory: the programmer assumes there is enough of it; the compiler makes sure there is enough of it (or fails to compile); the runtime system throws an exception in case the compiler was wrong (usually due to incorrect assumptions about the platform and possible contingencies).

By Mark Evans at Tue, 2004-08-17 22:33 | login or register to post comments