Smart pointers instead of GC?

[Manu]

On 2 February 2014 06:07, Adam Wilson <flyboynw at gmail.com> wrote:

> On Sat, 01 Feb 2014 02:15:42 -0800, Manu <turkeyman at gmail.com> wrote:
>
>>
>> Why is ARC any worse than GC? Why is it even a compromise at the high
>> level?
>> Major players have been moving away from GC to ARC in recent years. It's
>> still a perfectly valid method of garbage collection, and it has the
>> advantage that it's intrinsically real-time compatible.
>>
>>
> Define Major Players? Because I only know about Apple, but they've been
> doing ARC for almost a decade, and IIRC, like GC's, it's not universally
> loved there either. Microsoft is desperately trying to get people to move
> back to C++ but so far the community has spoken with a resounding "You can
> pry C#/.NET from our cold, dead, hands." Java has shown no particular
> interest in moving away from GC's probably because their GC is best in
> class. Even games are starting to bring in GC's (The Witcher 2 for example,
> and almost all of the mobile/casual games market, which is actually
> monetarily bigger than the triple-A games market.)


You didn't say why ARC is worse than GC?

I have my suspicious that the witcher guys would have been perfectly
(perhaps MORE happy) with ARC, if it were possible.
It's possible to write a GC in C++, but it's impossible to use ARC without
compiler support, which C++ does not and never will have, and as a result,
it wasn't an option to them.
You can't say they picked one over the other when one simply wasn't
available. Their use of a GC shows they appreciate the convenience of
garbage collection, but it doesn't say anything about GC vs ARC.

 I don't think realtime software is becoming an edge case by any means,
>> maybe 'extreme' realtime is, but that doesn't change the fact that the GC
>> still causes problems for all realtime software.
>>
>>
> Yes, but my point is that there is very little real-time software written
> as a percentage of all software written, which, by definition, makes it an
> edge-case. Even vehicle control software is no longer completely real-time.
> [I just happen to know that because that's the industry I work in. Certain
> aspects are, with the rest scheduled out.] And more to the point, D has
> made no claim about it's suitability for RT software and I have seen little
> demand for it outside a very small very vocal minority that is convinced
> that it has the dynamic resource management panacea if everyone would just
> do as they say.


So answer, why is a GC so much preferable to ARC?
GC forces you into one (poorly implemented) paradigm, which is
fundamentally incompatible with many tasks.
ARC might force you to think about weak references... but is that really as
hard as you say?
It's possible an ARC solution might optionally have a GC in the background
to collect cycles (for those not interested in dealing with the cognitive
load of circular reference as you are worried). This is fine, as long as
the aggressive users can turn that off, and deal with their circular
reference issues directly. Under an approach like this there are far more
options in terms of how different users can approach the garbage collection
in their apps, and ALL USERS would still have access to phobos.
I don't see them as mutually exclusive. They are quite complimentary.

 I personally believe latency and stuttering is one of the biggest usability
>> hindrances in modern computing, and it will become a specific design focus
>> in software of the future. People are becoming less and less tolerant of
>> latency in all forms; just consider the success of iPhone compared to
>> competition, almost entirely attributable to the silky smooth UI
>> experience. It may also be a telling move that Apple switched to ARC
>> around
>> the same time, but I don't know the details.
>>
>>
> I use .NET every day, seriously not one day goes by when I haven't touched
> some C# code. I can happily report that you are *ahem* wrong. Even Visual
> Studio 2013 doesn't stutter often, and only when I am pulling in some
> massive third-party module that may or may not be well written. Ironically,
> it is VisualD, it of D code fame that most slows down VS for me. I write
> software in C# every day I can happily report that I have yet to have a
> problem with stuttering in my code that wasn't of my own devise. (If you
> forget to asynchronously call that web-service it WILL stutter)
>
> And that's a point. I can write software in C# that works will without
> having to worry about circular references or if my data prematurely falls
> out of scope or any other of the details that are associated with ARC. And
> for my not-effort, I pay an effective cost of 0. Win-win. You're demanding
> that to suit your needs, we make a massive philosophical and language
> change to D that will incur HIGHER cognitive load on programmers for
> something that will not measurably improve the general use case? Ahem,
> that's good for D how?
>

Can you tell me your experience with C# on embedded hardware with
bugger-all memory? I can; it doesn't work (although to be fair, the GC is
not the only issue there).
It's also like you seem to think D's GC experience is comparable to C#.
It's not, D has a terrible GC, and there seems to be almost no motion to
fix or improve it.

Can it EVER be anywhere near as good as C# or Java? Where are the proposals
to get it there?
And even then, what is the resource overhead? How much ambient memory
overhead/loss will I suffer as a consequence? What if my platform is only
single-core?

 I also firmly believe that if D - a native compiled language familiar to
>> virtually all low-level programmers - doesn't have any ambition to service
>> the embedded space in the future, what will? And why not?
>> The GC is the only thing inhibiting D from being a successful match in
>> that
>> context. ARC is far more appropriate, and will see it enter a lot more
>> fields.
>> What's the loss?
>>
>>
> Cognitive load. How many details does the programmer have to worry about
> per line of code. Ease-of-use. A GC is easier to use in practice. You can
> say well they should learn to use ARC because it's better (for certain
> definitions of better) but they won't. They'll just move on. I'd say that's
> a pretty big loss.
>
> And based on my conversations with Walter, I don't think that D was ever
> intended to make a play for the embedded space. If D can be made to work
> there great, but Walter, as near as I can tell, has no interest in tying
> the language in knots to make it happen. So that's a non-issue. And let's
> be honest, the requirements of that space are fairly extreme.


But D ticks all the boxes, except that one... and it's an important field
that isn't covered by the rest of the landscape of emerging or trendy
languages.

 I think it's also telling that newcomers constantly raise it as a massive
>> concern, or even a deal-breaker. Would they feel the same about ARC? I
>> seriously doubt it. I wonder if a poll is in order...
>> Conversely, would any of the new-comers who are pro-GC feel any less happy
>> if it were ARC instead? $100 says they probably wouldn't even know, and
>> almost certainly wouldn't care.
>>
>
> I DON'T see a majority of newcomers raising an issue with the GC, I only
> see it from newcomers with some pretty extreme latency requirements,
> primarily for the real-time crowd. The majority of newcomers aren't
> interested in RT work. I think you're falling prey to confirmation bias
> here.


I never said anything about a majority, re-read my statement. But it does
come up all the time.
Are you surprised that the RT crowd are attracted to D? It's precisely what
they've been waiting for all these years.
There's just this one single stumbling block that seems to make every
single one of them very nervous.

I attended a small graphics/systems programming event yesterday, there were
about 40-50 people there. I hadn't caught up with the organisers for years,
they asked me what I had been up to, I mentioned I had been working a lot
with D in my spare time. They were interested, conversations went a lot
like this:

[among other comments]
"Oh yeah, I heard about that... we'd love you to come and give a talk about
it some time."
(more people overheard and approached the conversation)
"I was really interested in D, but then I realised that the GC isn't really
optional like the website claims, and stopped"
(more people approach)
"I tried it once, but I don't think it's practical for the same reason I
had to give up C#"
(small crowd, ~10 interested in hearing about it)
"I love C#, if I could use it for work, I would!" (note: for my money, D
actually offers to my kind what C# teases you with, but hangs just out of
reach)
"so, can you actually use D without the GC?"
me: "Erm. Well..."

Etc.

There was really surprising interest, and I ended out drinking beers with 4
guys who were really interested to hear more about it.
Many of them HAD heard about D, but immediately wrote it off, like C#.
There is a massive potential audience here, I've been saying for a long
time, D is the language that game devs and other realtime programmers want,
but they're very conservative, and this particular issue is an absolute red
flag.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140203/b8eb6a2a/attachment-0001.html>