I thought J-EAI ( <a href="http://www.process-one.net/en/jeai/">http://www.process-one.net/en/jeai/</a> ) is somewhat like ESB (ESB is mentioned in J-EAI user guide) solution but had no time to check it.<br>Maybe people from Process One on the list will explain what it is about and its destiny?
<br><br>Regards,<br>Kirill.<br><br><div class="gmail_quote">2008/1/16 Bob Calco <<a href="mailto:bobcalco@tampabay.rr.com">bobcalco@tampabay.rr.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">I first heard about Erlang reading the following book about Oz:</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"><a href="http://www.amazon.com/Concepts-Techniques-Models-Computer-Programming/dp/0262220695/" target="_blank">http://www.amazon.com/Concepts-Techniques-Models-Computer-Programming/dp/0262220695/
</a></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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. </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">If only there was more time in a day!</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p style="text-indent: -0.25in;"><span style="font-size: 11pt; color: rgb(31, 73, 125);"><span>-<span>
</span></span></span><span style="font-size: 11pt; color: rgb(31, 73, 125);">Bob Calco</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<div style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0in 0in 0in 4pt;">
<div>
<div style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0in 0in;">
<p><b><span style="font-size: 10pt;">From:</span></b><span style="font-size: 10pt;">
<a href="mailto:erlang-questions-bounces@erlang.org" target="_blank">erlang-questions-bounces@erlang.org</a>
[mailto:<a href="mailto:erlang-questions-bounces@erlang.org" target="_blank">erlang-questions-bounces@erlang.org</a>] <b>On Behalf Of </b>alex alvarez<br>
<b>Sent:</b> Tuesday, January 15, 2008 8:20 PM<br>
<b>To:</b> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<b>Subject:</b> Re: [erlang-questions] concurrency developments</span></p>
</div>
</div>
<p> </p>
<div align="center">
<table style="width: 100%;" border="0" cellpadding="0" cellspacing="0" width="100%">
<tbody><tr>
<td style="padding: 8pt;" valign="top">
<p style="margin-bottom: 12pt;"><span style="font-size: 10pt;">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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
-Alex</span></p>
<p style="margin-bottom: 12pt;"><span style="font-size: 10pt;"><br>
---------[ Received Mail Content ]----------<br>
<br>
<b>Subject : </b>Re: [erlang-questions] concurrency developments<br>
<br>
<b>Date : </b>Tue, 15 Jan 2008 17:25:48 -0700<br>
<br>
<b>From : </b>Travis Jensen <<a href="mailto:travis.jensen@gmail.com" target="_blank">travis.jensen@gmail.com</a>><br>
<br>
<b>To : </b>Erlang Questions <<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>><br>
<br>
<br>
<br>
<br>
<br>
The answer to that seems to be "start more JVMs" on the Java side
and <br>
<br>
then force the concurrency "issues" into the database. ! It is
going to <br>
<br>
be difficult to "rebuild" the JVM (and the CLR ) in a concurrent <br>
<br>
fashion because of the depth of penetration they have: the inertia <br>
<br>
alone will keep it from moving. Too many companies have too much code <br>
<br>
invested, and Sun and Microsoft have both shown that backwards <br>
<br>
compatibility is paramount, regardless of future pain caused.<br>
<br>
<br>
<br>
The flipside of that coin is something like Python, which has the <br>
<br>
agility and potentially the community, but has far too many use cases <br>
<br>
in the non-concurrent realm (basic scripting) to want to make that <br>
<br>
change. I don't think Ruby has the community to make the change. <br>
<br>
Scala has some interesting aspects, but because it is tied to the <br>
<br>
anchor of a JVM, they'll be hard pressed to really make it work (all <br>
<br>
in my opinion, of course :).<br>
<br>
<br>
<br>
Groovy Actors just seems like a very immature Stackless Python, which, <br>
<br>
while a reasonable model, is limited significantly by its underlying <br>
! <br>
technology.<br>
<br>
<br>
<br>
tj<br>
<br>
<br>
<br>
On Jan 15, 2008, at 12:19 PM, alex alvarez wrote:<br>
<br>
<br>
<br>
> I myself believe that their biggest hurdle is JVM's ability or <br>
<br>
> inability to scale. Not only internally, but also in terms of <br>
<br>
> system resources. Given that I work daily with huge frameworks, <br>
<br>
> like Java and .NET, I'm wondering how their respective companies <br>
<br>
> intend to move to fully utilization of multi-processor (multi-core) <br>
<br>
> systems. It's very different when you have a (relatively) lite <br>
<br>
> system like Erlang, which in itself was built for this work, compare <br>
<br>
> to systems that huge. Having said that these companies have enough <br>
<br>
> resources and interest to turn things around.<br>
<br>
><br>
<br>
><br>
<br>
><br>
<br>
><br>
<br>
><br>
<br>
> ---------[ Received Mail Content ]----------<br>
<br>
><br>
<br>
> Subject : Re: [erlang-questions] concurrency ! developments<br>
<br>
><br>
<br>
> Date : Tue, 15 Jan 2008 14:47:44 +0300<br>
<br>
><br>
<br>
> From : "Kirill Zaborski" <br>
<br>
><br>
<br>
> To : "Hynek Vychodil" <br>
<br>
><br>
<br>
> Cc : <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<br>
><br>
<br>
><br>
<br>
><br>
<br>
> So you say that performance doesn't matter?<br>
<br>
><br>
<br>
> Somewhat strange statement from engineer.<br>
<br>
><br>
<br>
><br>
<br>
><br>
<br>
> P.S. In some circumstances it can be negligible and I don't deny other<br>
<br>
><br>
<br>
> benefits from immutalbe variables. Just point to not very rare <br>
<br>
> issues with<br>
<br>
><br>
<br>
> Java GC which could be solved in GC assuming immutable variables <br>
<br>
> (which make<br>
<br>
><br>
<br>
> it simpler as far as I understand).<br>
<br>
><br>
<br>
><br>
<br>
><br>
<br>
> Regards,<br>
<br>
><br>
<br>
> Kirill.<br>
<br>
><br>
<br>
><br>
<br>
><br>
<br>
> On Jan 15, 2008 2:37 PM, Hy! nek Vychodil wrote:<br>
<br>
><br>
<br>
><br>
<br>
>! ;<br>
<br>
> > It isn't matter of performance, it is about security, reliability <br>
<br>
> and<br>
<br>
><br>
<br>
> > bug hunting.<br>
<br>
><br>
<br>
> ><br>
<br>
><br>
<br>
> > On 1/15/08, Kirill Zaborski wrote:<br>
<br>
><br>
<br>
> > > And also normally better GC performance coming from immutable <br>
<br>
> variables?<br>
<br>
><br>
<br>
> > Not<br>
<br>
><br>
<br>
> > > requiring intricate GC options.<br>
<br>
><br>
<br>
> > ><br>
<br>
><br>
<br>
> > ><br>
<br>
><br>
<br>
> > > On Jan 15, 2008 1:27 PM, Hynek Vychodil < <br>
<br>
> <a href="mailto:vychodil.hynek@gmail.com" target="_blank">vychodil.hynek@gmail.com</a>><br>
<br>
><br>
<br>
> > wrote:<br>
<br>
><br>
<br>
> > > ><br>
<br>
><br>
<br>
> > > > ... and where is immutable variables, where is side
effect free<br>
<br>
><br>
<br>
> > > > functional programming? Where is funny declarative (easy <br>
<br>
> readable)<br>
<br>
><br>
<br>
> > > > syn! tax?<br>
<br>
><br>
<br>
> > > ><br>
<br>
><br>
<br>
> &g t; > > Groovy is death way.<br>
<br>
><br>
<br>
> > > ><br>
<br>
><br>
<br>
> > > ><br>
<br>
><br>
<br>
> > > ><br>
<br>
><br>
<br>
> > > ><br>
<br>
><br>
<br>
> > > > On 1/15/08, Christian S wrot! e:<br>
<br>
><br>
<br>
> > > > > Where are process links? Where are super vision tree
infra- <br>
<br>
> structure?<br>
<br>
><br>
<br>
> > > > > Where is remote-node messaging transparency?<br>
<br>
><br>
<br>
> > > > ><br>
<br>
><br>
<br>
> > > > > > <a href="http://www.groovyactors.org/" target="_blank">http://www.groovyactors.org/</a><br>
<br>
><br>
<br>
> > > > > _______________________________________________<br>
<br>
><br>
<br>
> > > > > erlang-questions mailing list<br>
<br>
><br>
<br>
> > > > > <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<br>
><br>
<br>
> > > > >
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
><br>
<br>
> > > > ><br>
><br>
<br>
> > > ><br>
<br>
><br>
<br>
> > > ><br>
<br>
><br>
<br>
> > > > --<br>
<br>
><br>
<br>
> > > > --Hynek (Pichi) Vychodil<br>
<br>
><br>
<br>
> > > ><br>
<br>
><br>
<br>
> > > ><br>
<br>
><br>
<br>
> > > ><br>
<br>
><br>
<br>
> > > > _______________________________________________<br>
<br>
><br>
<br>
> > > > erlang-questions mailing list<br>
<br>
><br>
<br>
> > > > <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<br>
><br>
<br>
> > > > <a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
><br>
<br>
> > > ><br>
<br>
><br>
<br>
> > ><br>
<br>
><br>
<br>
> > ><br>
<br>
><br>
<br>
> ><br>
<br>
> !<br>
<br>
> ><br>
<br>
><br>
<br>
> > --<br>
<br>
><br>
<br>
> > --Hynek (Pichi) Vychodil<br>
<br>
><br>
<br>
> ><br>
<br>
><br>
<br>
> _______________________________________________<br>
<br>
> erlang-qu! estions mailing list<br>
<br>
> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<br>
&g t; <a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
<br>
</span></p>
</td>
</tr>
</tbody></table>
</div>
<p><span style="font-size: 10pt;"> </span></p>
</div>
</div>
</div>
<br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">
http://www.erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote></div><br>