The Next Mainstream Programming Language: A Game Developer's

[Robert Fraser]

Heh, guess I've been using mesage-based concurrency for a while without knowing there was anything special about it. But, if I'm understanding this right, in an iterative language, if there _is_ any state shared between actors, you still need explicit locking, neh?

eao197 Wrote:

> On Thu, 19 Jul 2007 19:39:59 +0400, Sean Kelly <sean at f4.ca> wrote:
> 
> > eao197 wrote:
> >> On Thu, 19 Jul 2007 02:54:29 +0400, Sean Kelly <sean at f4.ca> wrote:
> >>> Now that I'm learning about Erlang I'm discovering that it seems to  
> >>> work a lot like how I wanted to approach concurrency in D, so I'm  
> >>> definitely going to try and find some time to play with it.
> >>  The Scala developers have tried to implement something similar to  
> >> Erlang as a Scala's library 'Actors' [1].
> >> Because of some Scala features (especially pattern matching and symbols  
> >> as method names) Scala code looks like Erlang.
> >
> > All good points.  And I concede that it would be difficult to achieve  
> > the level of concurrency used in Erlang applications in an imperative  
> > language like D.  But I do believe that the basic style of programming  
> > could be used with reasonable results.
> 
> It's true. I have used at least last five years -- we have developed our  
> own agent-oriented framework in C++ and have used it in several projects.  
> Agents interoperate each to another only by messages. Agents handle  
> messages by events (special object methods) and special entity,  
> dispatcher, dispatches agent events to one of him worker threads. Some  
> agents can share single worker thread, some agents can own their own  
> thread (active agents).
> 
> But as a consequence of C++ usage our code much more verbose than Erlang :(
> 
> That approach changes way of thinking completely. So now I'm a  
> message-passing addicted man :))
> 
> But because message-passing in C++ more expensive than in Erlang, then it  
> is necessary to divide application into rather big parts (agents). And all  
> communication inside those parts (agent) make via ordinal synchorized  
> calls, but there is almost no traditional multithreading programming in  
> agent implementation. For example, our biggest project, which has been  
> delevoped using that framework, now consists near two hundred agents and  
> more than 90 threads.
> 
> -- 
> Regards,
> Yauheni Akhotnikau