Swift does away with pointers == pervasive ARC

[Manu via Digitalmars-d]

On 17 June 2014 18:36, Nick Sabalausky via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 6/17/2014 2:56 AM, "Ola Fosheim Grøstad"
> <ola.fosheim.grostad+dlang at gmail.com>" wrote:
>>
>> On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
>>>
>>> Well, I think interesting part we're trying to look at here is the
>>> ARC's impact on speed.
>>
>>
>> ARC without deep whole program analysis is bound to be slow.[...]
>
>
> Right, but what I'm mainly curious about is "How much slower?" Depending how
> the numbers play out, then as Manu has mentioned, it could be that the
> relaxed memory requirements and amortized cost are enough to make it a good
> tradeoff for a lot of people (Like Manu, I have some interest in
> soft-realtime as well).
>
> But I'm new to ARC, never even used ObjC, so I don't really even have much
> frame of reference or ballpark ideas here. So that's why I'm interested in
> the whole "How much slower?" Your descriptions of the ins and outs of it,
> and Apple's motivations, are definitely interesting. But even if nothing
> else, Manu's certainly right about one thing: What we need is some hard
> empirical data.

Andrei posted a document some time back comparing an advanced RC
implementation with "the best GC", and it performed remarkably well,
within 10%!
D does not have 'the best GC'. I doubt D's GC is within 10% of 'the best GC'.
In addition, my colleagues have reported no significant pain working
with ARC on iOS, whereas Android developers are always crying about
the GC by contrast.

I can visualise Walter's criticisms, but what I don't know is whether
his criticisms are actually as costly as they may seem? I also haven't
seen the compilers ability to eliminate or simplify that work, and the
circumstances in which it fails. It's conceivable that simply
rearranging an access pattern slightly may offer the compiler the
structure it needs to properly eliminate the redundant work.

The thing is, I don't know! I really don't know, and I don't know any
practical way to experiment with this. D theoretically offers many
opportunities for ARC optimisation that other languages don't via it's
rich type system, so direct comparisons via O-C could probably be
reasonably considered to be quite conservative.

Here's what I do know though; nobody has offered conception of a GC
that may be acceptable on a memory limited device, and it's also not
very acceptable just by nature (destructors are completely broken;
should be removed (like C#), concentrated cost as opposed to amortised
cost).
As far as I know, there is NO OTHER CHOICE.
Either somebody invents the fantasy GC, or we actually *experiment* with ARC...

We know: GC is unacceptable, and nobody has any idea how to make one that is.
We don't know: ARC is acceptable/unacceptable. Why.

What other position can I take on this issue?