[erlang-questions] concurrency developments

[Travis Jensen]

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" <qrilka@REDACTED>
>
> To : "Hynek Vychodil" <vychodil.hynek@REDACTED>
>
> 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)
>
> > > > syntax?
>
> > > >
>
> > > > 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-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/20080115/c542f098/attachment.htm>