[erlang-questions] concurrency developments

Wed Jan 16 22:19:33 CET 2008

On 16-Jan-08, at 4:52 PM, alex alvarez wrote:

> Very interesting!  Oz is definitely on the wild side.  Fumes from  
> the sixties must still be lingering around in some universities.

Universities are often built on top of old hippie burial grounds!

—Toby

>
>
>
>
> ---------[ Received Mail Content ]----------
>
> Subject : RE: [erlang-questions] concurrency developments
>
> Date : Wed, 16 Jan 2008 06:40:26 -0500
>
> From : "Bob Calco" <bobcalco@REDACTED>
>
> To : "'alex alvarez'" <eajam@REDACTED>,	<erlang-questions@REDACTED>
>
>
>
> 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  
> compa! rative 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 desi! gn 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. Als! o, code generation  
> tools, i.e., software factories, to make rapid deve lopment 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 appe! ared 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
>
>
> To : Erlang Questions
>
>
>
>
>
>
>
>
>
>
>
> 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 commun! ity 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-p! rocessor (multi- 
> core)
>
>
>
> > systems. It's very differen t 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
>
>
>
> > an! d
>
>
>
> >
>
>
>
> > > 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
>
>
>
> >
>
>
>
> > > > > er! lang-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
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

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