<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="State"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:purple;
        text-decoration:underline;}
p
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:Arial;
        color:navy;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>The only problem with a new paradigm usually
is that the old one is so familiar and well-known </span></font><font size=2
color=navy face=Wingdings><span style='font-size:10.0pt;font-family:Wingdings;
color:navy'>J</span></font><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I have been writing java code for ages, so
I have something to compare against. Having no exposure to non-C family
languages, learning erlang syntax and programming paradigms may seem like
trying ot understand Escher drawings – you have to break something in
your head to understand it. But once you do, you get great payoffs.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>The terrible erlang code that I write is
about 3-7 times more compact than similar java code I would’ve written
for the same purpose. In fact after I started programming in erlang; my java
code became a lot more compact and understandable than it used to be. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Speaking about JVM and CLR, there are
great developments going in those camps, but those will deliver only after the
NEW code will be written. Lots of attention is being paid to the parallelism and
concurrency, but the old code performance will not improve automagically. On
the contrary, most of the existing erlang code will get performance benefits with
more cores. And the key to this is the fact that the fundamental building
blocks in erlang are processes, not objects. In some sense one may say that the
erlang VM has higher level of abstraction than JVM or CLR. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>By the way, that brings another interesting
question. As far as I understand, good manycore scalability is a side-effect of
the VM design. Thus IMHO it is just a coincidence that erlang runtime gets
advantage with the new processors. Was this expected back in 1980s? What other
jewels may be hidden there? </span></font><font size=2 color=navy
face=Wingdings><span style='font-size:10.0pt;font-family:Wingdings;color:navy'>J</span></font><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>BR<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Dmitri<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> erlang-questions-bounces@erlang.org
[mailto:erlang-questions-bounces@erlang.org] <b><span style='font-weight:bold'>On
Behalf Of </span></b>alex alvarez<br>
<b><span style='font-weight:bold'>Sent:</span></b> 16. tammikuuta 2008 3:20<br>
<b><span style='font-weight:bold'>To:</span></b> erlang-questions@erlang.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [erlang-questions]
concurrency developments</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>

<div align=center>

<table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0 width="100%"
 style='width:100.0%'>
 <tr>
  <td valign=top style='padding:8.0pt 8.0pt 8.0pt 8.0pt'>
  <p class=MsoNormal style='margin-bottom:12.0pt'><font size=2
  face="Times New Roman"><span style='font-size:10.0pt'>Well, in the case of <st1:place
  w:st="on"><st1:City w:st="on">CLR</st1:City>, <st1:State w:st="on">MS</st1:State></st1:place>
  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<o:p></o:p></span></font></p>
  <p class=MsoNormal><font size=2 face="Times New Roman"><span
  style='font-size:10.0pt'><br>
  ---------[ Received Mail Content ]----------<br>
  <br>
  <b><span style='font-weight:bold'>Subject : </span></b>Re: [erlang-questions]
  concurrency developments<br>
  <br>
  <b><span style='font-weight:bold'>Date : </span></b>Tue, 15 Jan 2008 17:25:48
  -0700<br>
  <br>
  <b><span style='font-weight:bold'>From : </span></b>Travis Jensen
  <travis.jensen@gmail.com><br>
  <br>
  <b><span style='font-weight:bold'>To : </span></b>Erlang Questions
  <erlang-questions@erlang.org><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>
  <qrilka@gmail.com><br>
  ><br>
  <br>
  > To : "Hynek Vychodil" <br>
  <vychodil.hynek@gmail.com><br>
  ><br>
  <br>
  > Cc : erlang-questions@erlang.org<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>
  > vychodil.hynek@gmail.com><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>
  > > > > > > http://www.groovyactors.org/<br>
  <br>
  ><br>
  <br>
  > > > > > _______________________________________________<br>
  <br>
  ><br>
  <br>
  > > > > > erlang-questions mailing list<br>
  <br>
  ><br>
  <br>
  > > > > > erlang-questions@erlang.org<br>
  <br>
  ><br>
  <br>
  > > > > >
  http://www.erlang.org/mailman/listinfo/erlang-questions<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>
  ><br>
  <br>
  > > > ><br>
  <br>
  ><br>
  <br>
  > > > > _______________________________________________<br>
  <br>
  ><br>
  <br>
  > > > > erlang-questions mailing list<br>
  <br>
  ><br>
  <br>
  > > > > erlang-questions@erlang.org<br>
  <br>
  ><br>
  <br>
  > > > > http://www.erlang.org/mailman/listinfo/erlang-questions<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>
  > erlang-questions@erlang.org<br>
  <br>
  &g t; http://www.erlang.org/mailman/listinfo/erlang-questions<br>
  <br>
  <br>
  <br>
  <br>
  <o:p></o:p></span></font></p>
  </td>
 </tr>
 </vychodil.hynek@gmail.com></qrilka@gmail.com>
</table>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>

</div>

</div>

</body>

</html>