D Language 2.0
Craig Black
craigblack2 at cox.net
Tue Jan 19 15:27:22 PST 2010
"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
More information about the Digitalmars-d
mailing list