D Language 2.0

[Craig Black]

"Leandro Lucarella" <llucax at gmail.com> wrote in message 
news:20100119173057.GD14794 at llucax.com.ar...
> Walter Bright, el 18 de enero a las 14:31 me escribiste:
>> > More seriously, I don't expect D to see much usage in the embedded
>> >market unless it becomes a huge success on the PC first (if then).
>> >But nothing you can do on the technical front will change that: it's
>> >mostly due to prejudice and preconceptions, not an actual
>> >cost-benefit evaluation of the language.
>>
>> Yeah, I know, I run into the pseudo-problem all the time of D using
>> garbage collection. I point out that you can call/use malloc in D as
>> easily as you can in C++, but it makes no difference. They're
>> convinced that gc will send their app to hell. <g>
>>
>> I fault Java, C#, Python, etc., for some of this anti-gc silliness
>> because those languages make it really hard to use malloc. They just
>> don't believe that malloc is trivial to use in D.
>
> Well, I think it's a little D's fault too, because several language
> features use the GC (and all the stdlib as well). It's trivial to use
> malloc in D, but, even when it's possible, it's not so easy to completely
> avoid the GC. You just have to be too careful, and I think the features
> that use the GC are not very well documented (same for Phobos).
>
> So I think the GC-will-get-in-the-way fear in D is not totally
> unjustified, even when malloc is trivial to use.

I would have to agree and this is one of my causes for hesisation in 
adopting D.  The code I write requires the highest performance possible.  I 
am concerned that when I port it over to D, I will have to avoid using a lot 
of D features that use the GC (built-in arrays, closures, standard library 
features, etc.)  in order to get the best possible performance.  D does not 
adhere to the C++ zero-overhead principle, and I see this as a risk.  So 
if/when I end up porting my code to D I may evolve my own dialect of D that 
uses only the subset of features that tend to provide the best performance.

I don't know if the GC will send my code to hell, but if the performance 
drops by more than 20% by porting it from C++ to D, then I would be 
disappointed.  The GC is a huge concern for me, and it's not an unreasonable 
concern.  I got about a 15% performance improvement by switching from the 
system allocator to nedmalloc, so my code is very sensitive to heap 
allocation performance.  I use dynamic arrays quite a lot, and if I switched 
all of these to use D's built-in GC-based arrays, I think I would see a 
tremendous performance drop.

Even so, I do hope to use D when I see its stability improve to the point 
where I can sell it to my boss and my coworkers.  There are a lot of great 
features and a lot of good work being done.  The rich feature set of the 
language is very attractive to me.  It can be frustrating that people tend 
to focus only on the negative aspects.  I think D is moving forward at a 
very good pace, especially when I compare it to C++.  The D language and the 
community that surrounds it has qualities that I have not seen anywhere 
else.  Altogether it seems headed in a promising direction, and I am 
appreciative of all the work that so many have put into it.

-Craig