The problem with the D GC

[Kyle Furlong]

%u wrote:
> == Quote from Kyle Furlong (kylefurlong at gmail.com)'s article
>> %u wrote:
>>> == Quote from Bill Baxter (dnewsgroup at billbaxter.com)'s article
>>>> Sean Kelly wrote:
>>>>>> This seems to be a very big issue.  The GC seems to be pretty much
>>>>>> useless right now if you're going to have a lot of floating point data
>>>>>> in your app.
>>>>> For what it's worth, I ran the test above with the modified GC in Tango,
>>>>> for 10000 iterations of the "while(1)" loop.  The default behavior
>>>>> roughly matched Phobos, with an 89 second run time and over 340MB of
>>>>> memory consumed and growing steadily.  Then I told the GC to not scan
>>>>> the arrays using the following calls:
>>>>>
>>>>>     gc.setAttr( data.ptr, GC.BlkAttr.NO_SCAN );
>>>>>     gc.setAttr( incoming.ptr, GC.BlkAttr.NO_SCAN );
>>>>>
>>>>> A test with these changes in place dropped the run time to 7 seconds
>>>>> with 43MB of memory consumed and not growing.
>>>>>
>>>>> I grant that this isn't quite as nice as if D just figured out whether
>>>>> to scan the block using TypeInfo, but at least it grants the programmer
>>>>> a way to customize GC behavior somewhat to tune application performance.
>>>>>  The only stipulation with the current implementation is that block
>>>>> attributes will not be preserved if an array is resized.  This isn't
>>>>> terribly difficult to fix, but I haven't done so yet.
>>>> I'd certainly be willing to do that sort of thing in my code to make the
>>>> problem go away in the short term.  In my case all of those setAttr
>>>> calls would be hidden away in library code, so it wouldn't make life any
>>>> harder for everyday use.
>>>> But it's not much use as a workaround until Tango is actually
>>>> downloadable somewhere.  :-)
>>>> Once Tango is available, though, that would certainly be better than the
>>>> alternative of rewriting my library to use malloc/free.  If that's going
>>>> to be necessary then I think I'll just as soon go back to C++ where at
>>>> least I can use smart pointers.  The integrated GC is the #1 reason I'm
>>>> using D in the first place, and if I can't realistically use that then I
>>>> might as well be using C++.
>>>> --bb
>>> I feel the same way. Without GC, D is just C++ with a few more features.
>> I do not think that this is even remotely valid. Think of everything you
>> arent doing in D. You arent hacking macros with the preprocessor, you
>> arent declaring methods outside of classes, globally overloading
>> operators... To say that D is C++ + GC + some other features is just
>> plain ignorant.
> 
> It's not ignorant from my viewpoint. You're assuming I care about the features you
> described.

What I'm trying to say is, that to say a language is just a sum of its 
features is incorrect. There are behaviors that arise from the 
interaction of features that can be good or bad. In D, I've found that 
these interactions are on the whole good. In C++, I've found that these 
interactions are on the whole bad.

I'm not trying to say your experiences with both are invalid, maybe you 
have been using them in a way in which the opposite is true. But for me, 
C++ as a whole doesn't feel right, and D as a whole does.