Mac Apps That Use Garbage Collection Must Move to ARC

Paulo Pinto via Digitalmars-d digitalmars-d at puremagic.com
Sun Feb 22 23:19:54 PST 2015


On Monday, 23 February 2015 at 05:54:06 UTC, Manu wrote:
> On 23 February 2015 at 14:11, Andrei Alexandrescu via 
> Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On 2/22/15 5:57 PM, Manu via Digitalmars-d wrote:
>>>
>>> I can easily visualise a way forward with RC.
>>
>>
>> Then do it. Frankly it seems to me you're doing anything you 
>> possibly can to
>> talk yourself out of doing work.
>
> Excellent technique to immediately invalidate everything 
> someone says.
> Thanks for that.
> You dismissed absolutely everything I said, and then imply that 
> I have
> no right to comment unless I do it myself.
> It's got nothing to do with doing work. ARC (or something like 
> it) is
> almost religiously opposed. We can't even have a reasonable
> conversation about it, or really explore it's implications 
> before
> someone (that ideally know's what they're doing) thinks about 
> writing
> code. There's no room for progress in this environment.
>
> What do you want me to do? I use manual RC throughout my code, 
> but the
> experience in D today is identical to C++. I can confirm that 
> it's
> equally terrible to any C++ implementation I've used. We have 
> no tools
> to improve on it.
> And whatever, if it's the same as C++, I can live with it. I've 
> had
> that my whole career (although it's sad, because we could do 
> much
> better).
> The problem, as always, is implicit allocations, and 
> allocations from
> 3rd party libraries. While the default allocator remains 
> incompatible
> with workloads I care about, that isolates us from virtually 
> every
> library that's not explicitly written to care about my use 
> cases.
> That's the situation in C++ forever. We're familiar with it, 
> and it's
> shit. I have long hoped we would move beyond that situation in D
> (truly the #1 fantasy I had when I first dove in to D 6 years 
> back),
> but it's a massive up-hill battle to even gain mindshare, 
> regardless
> of actual implementation. There's no shared vision on this 
> matter, the
> word is basically "GC is great, everyone loves it, use an RC 
> lib".
>
> How long do we wait for someone to invent a fantastical GC that 
> solves
> our problems and works in D? I think it's practically agreed 
> that no
> known design can work, but nobody wants to bite the bullet and 
> accept
> the fact.
> We need to admit we have an impassable problem, and then maybe 
> we can
> consider alternatives openly. Obviously, it would be 
> disruptive, but
> it might actually work... which is better than where we seem to 
> be
> heading (with a velocity of zero).
>
> The fact is, people who are capable of approaching this problem 
> in
> terms of actual code will never even attempt it until there's
> resounding consensus that it's worth exploring.

Personally I think what matters is getting D's situation 
regarding memory management sorted out, regardless out it will 
look like in the end.

If I am a bit too quick jumping the gun about GC, is that I have 
embraced GC languages in my line of work, so I tend to be aware 
that not all GCs are made alike and some like the ones from e.g. 
Aonix are good enough for real time situations, the ones someone 
dies if the GC runs on the wrong moment.

Maybe such GC quality is impossible to achieve in D, I don't know.

What I can say is that I cannot use D on my type of work and 
keeping up with everything that happens on the JVM, .NET and 
mobile space already keeps me busy enough.


More information about the Digitalmars-d mailing list