Go, D, and the GC

[deadalnix via Digitalmars-d]

On Friday, 9 October 2015 at 07:39:06 UTC, Shachar Shemesh wrote:
> On 08/10/15 18:58, Marco Leise wrote:
>> Am Mon, 05 Oct 2015 13:42:50 +0000
>> schrieb Adam D. Ruppe <destructionator at gmail.com>:
>>
>>> On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote:
>>>> Not on the heap. There are many cases where the destructor
>>>> won't run and it is allowed by spec. We should do better.
>>>
>>> To be fair, if you new a struct in C++ and never delete it, 
>>> the
>>> destructor will never run there either. D's in the same boat 
>>> in
>>> that regard.
>>
>> But the D boat reads "Garbage Collector". And besides, D now
>> runs dtors on new'd structs. The "many cases" may be different
>> ones than you imagine.
>>
>
> There is an inherent contradiction between GC and destruction. 
> The GC's unpredictable nature runs counter to the reason you 
> usually want a struct to have a destructor in the first place. 
> With that said, D has improved on that front.
>
> By this discussion started out with using containers in order 
> to avoid using the GC. As such, those cases are less relevant 
> to this discussion, I think.
>
> You'll also notice that the C++ heap does not suffer from 
> unpredictability. You either delete at a specified time 
> (typically, from some RAII's destructor), or leak it, in which 
> case, well, you leaked it.
>
> Shachar

Well it depends. destruction and GC are about releasing 
resources. You want eager resource release for scarce resources, 
like file handler. For resources that aren't as scarce, strategy 
like GC make sense.

But GC only works for memory. One also may want to GC other 
resources, granted they aren't too scarce. dtor make sense for 
this.

It is also very useful as a safety net. When the object is 
released, if it still hold handle to scarce resource, it make 
sense to log and release it, or something similar. That is surely 
better than running out of the resource and crashing.