On 12/18/11 6:19 AM, Alex Rønne Petersen wrote:
On 18-12-2011 12:45, Somedude wrote:
Le 18/12/2011 12:13, Ruslan Mullakhmetov a écrit :
I do not want to make a flame over D vs C++11.
...
Once again, i'm not trying to make a holywar. I'm D lover myself. But a
lot of people do not consider this benefits of D enough to shift to it
as for my opinion and experience.
These people will not change their mind whatever you throw at them. For
them, it's a matter of religion, not a matter of comparison. We
shouldn't bother pleasing such or such group of people.
BTW, your comparison with Erlang misses one crucial point: performance.
A part for some very specific applications for which it is designed,
Erlang's general performance is simply not comparable to that of D. A
lot of D's complex set of features is geared towards increasing runtime
performance. Erlang just doesn't compare.
On the other hand, Erlang's runtime is built around message-passing. I
*extremely strongly doubt* that you can get similar performance out of
message-passing in D, for two reasons:
1) The Erlang runtime is written in highly optimized C.
2) Erlang uses better garbage collection strategies than D.
On point 1: Of course, you can write a message-passing implementation in
D that's basically just glorified C, but that defeats the point of using
D in the first place IMHO.
I'm not so sure. That seems to presuppose that use of any non-C features
of D exacts a performance overhead, something I'd disagree with.
On point 2: This is highly unlikely to change. It seems (from reading
the NG's past discussions) that there is virtually no interest from the
core devs of D to do The Right Thing to make precise garbage collection
possible, sadly (and neither to make thread-local GC possible, and other
such techniques (Erlang runs a separate GC per Erlang process, very
successfully)).
Walter and I are both interested in making the GC precise.
Yes, Erlang's emulator is not good in raw performance. It was never
geared for this (that's why it has easy interfacing with C for
performance-sensitive code). However, things like HiPE improve the
situation.
All languages have their place, and Erlang is still going strong in the
world of massive concurrency.
That may be the case, perhaps outside Ericsson. I know a few people at
Ericsson, and according to them the use of Erlang there is waning. No
new projects are started in Erlang and some production software is
rewritten in C++.
I doubt D will be able to challenge this
until its GC issues have been resolved (and even then, D is nowhere near
as convenient, lacking fault tolerance and location transparency;
sometimes these traits are *much* more desirable than raw performance
when dealing with concurrency on such high levels).
We need to improve the GC, that's a given. Then the question remains
whether fault tolerance and location transparency are language features
or library/environment/deployment attributes.
Andrei
