[erlang-questions] concurrency developments

[Bob Calco]

What's the J stand for, I wonder? When I stumbled on it awhile back I
figured it was Java-based just because of the J.

 

If J-EAI is written in Erlang I will take a new look at it. I am actively
looking for ways to bring Erlang in where I work.  Thanks for getting me to
look at J-EAI again.

 

-          Bob

 

 

From: Kirill Zaborski [mailto:qrilka@REDACTED] 
Sent: Wednesday, January 16, 2008 6:59 AM
To: bobcalco@REDACTED
Cc: alex alvarez; erlang-questions@REDACTED
Subject: Re: [erlang-questions] concurrency developments

 

I thought J-EAI ( http://www.process-one.net/en/jeai/ ) is somewhat like ESB
(ESB is mentioned in J-EAI user guide) solution but had no time to check it.
Maybe people from Process One on the list will explain what it is about and
its destiny? 

Regards,
Kirill.

2008/1/16 Bob Calco <bobcalco@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/026
2220695/ 

 

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



 


_______________________________________________
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/3c71ab0a/attachment.htm>