[erlang-questions] concurrency developments

Bob Calco bobcalco@REDACTED
Wed Jan 16 12:40:26 CET 2008


With respect to the CLR I note that they have some hard-core Haskellites driving the compiler development, not the least of which being Erik Meijer, who is on a mission to “democratize the cloud” with VB support for functional programming concepts – i.e., make middle tier development easy for Everyman. Developments like the CCR (Concurrency and Coordination Runtime), part of MS Robitics Studio, with its Port and PortSet abstractions, are additional major efforts to bring message-passing concurrency to .NET.

 

Also, don’t count the Rubyists out. Matz is building a VM for Ruby as of 2.0, and as I understand it much of the renewed interest in Erlang comes from folks disappointed at RoR’s scaling issues. At least, that’s partly how I rediscovered it.

 

I first heard about Erlang reading the following book about Oz:

 

http://www.amazon.com/Concepts-Techniques-Models-Computer-Programming/dp/0262220695/

 

There is a whole section of a chapter on concurrency dedicated to comparing Erlang and Oz—one of few languages to get such extensive comparative treatment.

 

I have long been an admirer of Oz, with its ambitious multi-paradigm agenda, and have been convinced for many years that it portends an era in which nanny runtimes embrace more than one computational model. But using it in real programs is hard for lack of library maturity and community support. I think the syntax is simply too foreign for most folks, which is sad. It has a tool called Gump so that you can design your own front end language to it, but I never had time to get into it. Ultimately, such a swiss army knife of a language (complete with the sidewinder missile option and a kitchen sink) is perhaps “too” versatile. It begs the question about the right way to do something, even as it facilitates every right way to do something.

 

Erlang is far simpler a language, proven in industry, with a runtime platform that is an architect’s wet dream in terms of satisfying rigorous scalability, availability and robustness requirements, given its very focused design goals.

 

I have recently decided to experiment writing a Ruby-like front end to Erlang, code named Emerld, which would generate Erlang code that would then be compiled (at least until I can learn the BEAM file format well enough to generate it directly). It could theoretically be retargeted to .NET or Java when either of the two got their act together for concurrency. That seems to me more a matter of when than if. Until then though I have committed myself to mastering Erlang, because I think it will give me a huge competitive edge in the new multi-core world we live in as a software designer and architect. 

 

Another line of thinking I’m pursuing is “What would be the killer app for Erlang?” in terms of getting wide-spread IT acceptance. Where I currently work, which is a large retail chain in the southeast, I think an ESB solution with built-in health & performance monitoring would be compelling. Also, code generation tools, i.e., software factories, to make rapid development of distributed supply chain systems much simpler, could also hit a sweet spot.

 

If only there was more time in a day!

 

-          Bob Calco

 

 

From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of alex alvarez
Sent: Tuesday, January 15, 2008 8:20 PM
To: erlang-questions@REDACTED
Subject: Re: [erlang-questions] concurrency developments

 


Well, in the case of CLR, MS is lately putting out so many frameworks and new stuff that I cannot count them out in this respect.  There's no reason why they could not refurbish the CLR w/ the necessary code and put out a new framework just to access the new functionality without braking backwards compatibility.   The Sun folks in many respects are a little bit on the catch up lately with regards to features that first appeared in .NET, but at the end of all weren't inherently new (ie. generics).

Now w/ regards to Erlang, which is meant for this type of massive concurrent work, my feeling is that the biggest problem/hurdle is not the back-end, but getting into the syntax and (more importantly) to mentally switch to a totally different format for paradigms.  Dr. Joe's book is d! efinitely a great help, but at least for me is coming slow but steady.  Maybe I'm completely wrong on this, but my feeling is also that Ericsson as a whole is not that into moving Erlang forward either.

BTW, sorry for talking about things that seem outside the Erlang realm, but the truth is that it does not stand alone in a vacuum and hence everything is related nowadays.

-Alex


---------[ Received Mail Content ]----------

Subject : Re: [erlang-questions] concurrency developments

Date : Tue, 15 Jan 2008 17:25:48 -0700

>From : Travis Jensen <travis.jensen@REDACTED>

To : Erlang Questions <erlang-questions@REDACTED>





The answer to that seems to be "start more JVMs" on the Java side and 

then force the concurrency "issues" into the database. ! It is going to 

be difficult to "rebuild" the JVM (and the CLR ) in a concurrent 

fashion because of the depth of penetration they have: the inertia 

alone will keep it from moving. Too many companies have too much code 

invested, and Sun and Microsoft have both shown that backwards 

compatibility is paramount, regardless of future pain caused.



The flipside of that coin is something like Python, which has the 

agility and potentially the community, but has far too many use cases 

in the non-concurrent realm (basic scripting) to want to make that 

change. I don't think Ruby has the community to make the change. 

Scala has some interesting aspects, but because it is tied to the 

anchor of a JVM, they'll be hard pressed to really make it work (all 

in my opinion, of course :).



Groovy Actors just seems like a very immature Stackless Python, which, 

while a reasonable model, is limited significantly by its underlying 
! 
technology.



tj



On Jan 15, 2008, at 12:19 PM, alex alvarez wrote:



> I myself believe that their biggest hurdle is JVM's ability or 

> inability to scale. Not only internally, but also in terms of 

> system resources. Given that I work daily with huge frameworks, 

> like Java and .NET, I'm wondering how their respective companies 

> intend to move to fully utilization of multi-processor (multi-core) 

> systems. It's very different when you have a (relatively) lite 

> system like Erlang, which in itself was built for this work, compare 

> to systems that huge. Having said that these companies have enough 

> resources and interest to turn things around.

>

>

>

>

>

> ---------[ Received Mail Content ]----------

>

> Subject : Re: [erlang-questions] concurrency ! developments

>

> Date : Tue, 15 Jan 2008 14:47:44 +0300

>

> From : "Kirill Zaborski" 

>

> To : "Hynek Vychodil" 

>

> Cc : erlang-questions@REDACTED

>

>

>

> So you say that performance doesn't matter?

>

> Somewhat strange statement from engineer.

>

>

>

> P.S. In some circumstances it can be negligible and I don't deny other

>

> benefits from immutalbe variables. Just point to not very rare 

> issues with

>

> Java GC which could be solved in GC assuming immutable variables 

> (which make

>

> it simpler as far as I understand).

>

>

>

> Regards,

>

> Kirill.

>

>

>

> On Jan 15, 2008 2:37 PM, Hy! nek Vychodil wrote:

>

>

>! ;

> > It isn't matter of performance, it is about security, reliability 

> and

>

> > bug hunting.

>

> >

>

> > On 1/15/08, Kirill Zaborski wrote:

>

> > > And also normally better GC performance coming from immutable 

> variables?

>

> > Not

>

> > > requiring intricate GC options.

>

> > >

>

> > >

>

> > > On Jan 15, 2008 1:27 PM, Hynek Vychodil < 

> vychodil.hynek@REDACTED>

>

> > wrote:

>

> > > >

>

> > > > ... and where is immutable variables, where is side effect free

>

> > > > functional programming? Where is funny declarative (easy 

> readable)

>

> > > > syn! tax?

>

> > > >

>

> &g t; > > Groovy is death way.

>

> > > >

>

> > > >

>

> > > >

>

> > > >

>

> > > > On 1/15/08, Christian S wrot! e:

>

> > > > > Where are process links? Where are super vision tree infra- 

> structure?

>

> > > > > Where is remote-node messaging transparency?

>

> > > > >

>

> > > > > > http://www.groovyactors.org/

>

> > > > > _______________________________________________

>

> > > > > erlang-questions mailing list

>

> > > > > erlang-questions@REDACTED

>

> > > > > http://www.erlang.org/mailman/listinfo/erlang-questions

>

> > > > >
>

> > > >

>

> > > >

>

> > > > --

>

> > > > --Hynek (Pichi) Vychodil

>

> > > >

>

> > > >

>

> > > >

>

> > > > _______________________________________________

>

> > > > erlang-questions mailing list

>

> > > > erlang-questions@REDACTED

>

> > > > http://www.erlang.org/mailman/listinfo/erlang-questions

>

> > > >

>

> > >

>

> > >

>

> >

> !

> >

>

> > --

>

> > --Hynek (Pichi) Vychodil

>

> >

>

> _______________________________________________

> erlang-qu! estions mailing list

> erlang-questions@REDACTED

&g t; http://www.erlang.org/mailman/listinfo/erlang-questions




 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080116/0dc7a094/attachment.htm>


More information about the erlang-questions mailing list