d future or plans for d3

[Andrei Alexandrescu]

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