[erlang-questions] concurrency developments

[Dmitri Girenko]

The only problem with a new paradigm usually is that the old one is so
familiar and well-known :-)

 

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.

 

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. 

 

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. 

 

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? :-)

 

BR

Dmitri

 

________________________________

From: erlang-questions-bounces@REDACTED
[mailto:erlang-questions-bounces@REDACTED] On Behalf Of alex alvarez
Sent: 16. tammikuuta 2008 3:20
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






 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080116/c5dc800b/attachment.htm>