The Next Mainstream Programming Language: A Game Developer's

[eao197]

On Thu, 19 Jul 2007 02:54:29 +0400, Sean Kelly <sean at f4.ca> wrote:

> Brad Roberts wrote:
>>  Erlang is indeed a very interesting system if for no other reason that  
>> it's fairly unique.  I wish I could find 3-6 months to really get my  
>> hands dirty with it, but alas, that's behind another dozen or so  
>> projects.  Anyone wanna be my lackey, I mean research assistant?  The  
>> pay would be crappy, the housing not free, and the hours sucky.. but  
>> it'd be fun, honest!
>
> 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.

But attempts to implement message passing model in a universal language  
(like Java, Scala, C++ or D) lead to some drawbacks. At first, active  
entities will be represented as threads. So, to pass message from one  
thread to another it is necessary to use some synchronization techniques  
(like mutexes and condition variables). But the price of synchronization  
of threads by OS mechanism is too high. Because of that maximum throughput  
is not too high [2]. In contast Erlang VM use its own synchronization  
mechanisms which are cheaper than OS ones. Another limitation is the count  
of parallel threads on each platfom.

Next, processes in Erlang are isolated. So Erlang VM can easyly wipe out  
any broken or dangling process without any interference to other  
processes` data. With OS threads in C++/D/Java programs it not so easy.  
Even if we terminate thread by some way there could be damaged or  
inconsistent data to which other thread refer.

Next (as addition to previous), Erlang is a pure functional language. So  
there no any global variables or shared data beetwen processes. Erlang  
simply doesn't allow processes to modity some shared variable. In a  
imperative language is very hard to write in such style, becasue some  
hidden link beetwen two threads` data can be introduced by a mistake.

Next, reliabilty of Erlang programs highly depend on specific mechanism of  
Erlang VM -- notification of other process termination. If two processes  
linked one to another than Erlang VM sents special messages about linked  
process termination with description and additional information.

Next, Erlang is a very successful and handy DSL for isolated processes  
communication. Special syntax and pattern matching make Erlang programs  
small and readable. In staticaly typed languages without pattern matching  
sending and receiving messages could be much more verbose.

Just my $0.02.

[1] http://lamp.epfl.ch/~phaller/doc/ActorsTutorial.html
[2] http://lampwww.epfl.ch/~odersky/papers/jmlc06.pdf

-- 
Regards,
Yauheni Akhotnikau