More radical ideas about gc and reference counting

[Walter Bright via Digitalmars-d]

On 5/10/2014 8:58 PM, Manu via Digitalmars-d wrote:
> This is truly a niche usage case though,

Come on! Like about 80% of the programs on any linux box? Like the OCR program I 
run? A payroll processing program? Any scientific numerical analysis program? 
Engineering programs?


> If you're prepared to label the largest entertainment industry on the
> planet a niche,

I'm not doing that.


> How many libs does DMD link?

We've gone over this before. You were concerned that the libraries you linked 
with were incompetently written, and implied that if ARC was pervasive, they 
would be competently written. I can guarantee you, however, that ARC leaves 
plenty of opportunity for incompetence :-)


> I'm hard pressed to think of any software I see people using every day
> which isn't realtime in some sense.

Programs you "see" by definition have a user interface. But an awful lot of 
programs are not seen, but that doesn't mean they aren't there and aren't 
running. See my list above.


>> Compiler improvements to improve on ARC are the same technology as used to
>> improve GC.
>>
>> You're essentially arguing that one is easy pickings and the other is
>> impractically difficult, but they're actually about the same level.
>
> Are they? This is the first I've heard such a claim. If that's the
> case,

Yes.


> then that why is there an argument?

Because if this was an easy problem, it would have been solved. In particular, 
if the ARC overhead was easily removed by simple compiler enhancements, why 
hasn't ARC taken the world by storm? It's not like ARC was invented yesterday.


> That work just needs to be done,

That's a massive understatement. This is PhD research topic material, not 
something I can churn out in a week or two if only I had a more positive 
attitude :-)

> but by all prior
> reports I've heard, awesome GC is practically incompatible with D for
> various reasons.

There is no such thing as a GC which would satisfy your requirements.

> No matter how awesome it is, it seems conceptually
> incompatible with my environment.

My point!

> I keep saying, I'm more than happy to be proved wrong (really!), but
> until someone can, then it's unfair to dismiss my arguments so
> easily...

I believe I have answered your arguments, not dismissed them.

> and I just don't think it's that unreasonable. ARC is an
> extremely successful technology, particularly in the
> compiled/native/systems language space (OC, C++/CX,

What was dismissed is the reality pointed out many times that those systems 
resolve the perf problems of ARC by providing numerous means of manually 
escaping it, with the resulting desecration of soundness guarantees.


> Rust).

Rust is not an extremely successful technology. It's barely even been implemented.


> Is there
> actually any evidence of significant GC success in this space?
> Successes all seem to be controlled VM based languages like Java and
> C#; isolated languages with no intention to interact with existing
> native worlds. There must be good reason for that apparent separation
> in trends?

There are many techniques for mitigating GC problems in D, techniques that are 
not available in Java or C#. You can even do shared_ptr<> in D. You can use 
@nogc to guarantee the GC pause troll isn't going to pop up unexpectedly. There 
are a bunch of other techniques, too.

ARC simply is not a magic, no problem solution one can use without careful 
thought in large, complex systems. (Of course, neither is GC nor any other 
memory management scheme.)