<style> p {margin-top:0px;margin-bottom:0px;} </style> <table border=0 width=100%% cellpadding=0 cellspacing=0 align=center> <tr> <td valign=top style='padding:8pt;'><font size=2>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<br><br><blockquote style="border-top: 1px solid rgb(204, 204, 204); margin: 0.8ex 0pt 0pt; padding-bottom: 1ex;"><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 <travis.jensen@gmail.com><br><br> <b>To : </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" <qrilka@gmail.com><br><br>><br><br>> To : "Hynek Vychodil" <vychodil.hynek@gmail.com><br><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>&gt!
 ;<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></vychodil.hynek@gmail.com></qrilka@gmail.com></blockquote></font></td></tr>
</table>