<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 2 February 2014 06:07, Adam Wilson <span dir="ltr"><<a href="mailto:flyboynw@gmail.com" target="_blank">flyboynw@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sat, 01 Feb 2014 02:15:42 -0800, Manu <<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><br></div></div><div class="im">
Why is ARC any worse than GC? Why is it even a compromise at the high level?<br>
Major players have been moving away from GC to ARC in recent years. It's<br>
still a perfectly valid method of garbage collection, and it has the<br>
advantage that it's intrinsically real-time compatible.<br>
<br>
</div></blockquote>
<br>
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.)</blockquote>
<div><br></div><div>You didn't say why ARC is worse than GC?</div><div><br></div><div>I have my suspicious that the witcher guys would have been perfectly (perhaps MORE happy) with ARC, if it were possible.</div><div>
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.</div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't think realtime software is becoming an edge case by any means,<br>
maybe 'extreme' realtime is, but that doesn't change the fact that the GC<br>
still causes problems for all realtime software.<br>
<br>
</blockquote>
<br></div>
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.</blockquote>
<div><br></div><div>So answer, why is a GC so much preferable to ARC?</div><div>GC forces you into one (poorly implemented) paradigm, which is fundamentally incompatible with many tasks.</div><div>ARC might force you to think about weak references... but is that really as hard as you say?</div>
<div>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.</div>
<div>I don't see them as mutually exclusive. They are quite complimentary.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I personally believe latency and stuttering is one of the biggest usability<br>
hindrances in modern computing, and it will become a specific design focus<br>
in software of the future. People are becoming less and less tolerant of<br>
latency in all forms; just consider the success of iPhone compared to<br>
competition, almost entirely attributable to the silky smooth UI<br>
experience. It may also be a telling move that Apple switched to ARC around<br>
the same time, but I don't know the details.<br>
<br>
</blockquote>
<br></div>
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)<br>

<br>
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?<br>
</blockquote><div><br></div><div>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).</div><div>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.</div>
<div><br></div><div>Can it EVER be anywhere near as good as C# or Java? Where are the proposals to get it there?</div><div>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?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
I also firmly believe that if D - a native compiled language familiar to<br>
virtually all low-level programmers - doesn't have any ambition to service<br></div><div class="im">
the embedded space in the future, what will? And why not?<br>
The GC is the only thing inhibiting D from being a successful match in that<br>
context. ARC is far more appropriate, and will see it enter a lot more<br>
fields.<br>
What's the loss?<br>
<br>
</div></blockquote>
<br>
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.<br>

<br>
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.</blockquote>
<div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think it's also telling that newcomers constantly raise it as a massive<br>
concern, or even a deal-breaker. Would they feel the same about ARC? I<br>
seriously doubt it. I wonder if a poll is in order...<br>
Conversely, would any of the new-comers who are pro-GC feel any less happy<br>
if it were ARC instead? $100 says they probably wouldn't even know, and<br>
almost certainly wouldn't care.<br>
</blockquote>
<br></div>
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.</blockquote>
<div><br></div><div>I never said anything about a majority, re-read my statement. But it does come up all the time.</div><div>Are you surprised that the RT crowd are attracted to D? It's precisely what they've been waiting for all these years.</div>
<div>There's just this one single stumbling block that seems to make every single one of them very nervous.</div><div><br></div><div>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:</div>
<div><br></div><div>[among other comments]</div><div>"Oh yeah, I heard about that... we'd love you to come and give a talk about it some time."</div><div>(more people overheard and approached the conversation)</div>
<div>"I was really interested in D, but then I realised that the GC isn't really optional like the website claims, and stopped"</div><div>(more people approach)</div><div>"I tried it once, but I don't think it's practical for the same reason I had to give up C#"</div>
<div>(small crowd, ~10 interested in hearing about it)</div><div>"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)</div>
<div>"so, can you actually use D without the GC?"</div><div>me: "Erm. Well..."</div><div><br></div><div>Etc.</div><div><br></div><div>There was really surprising interest, and I ended out drinking beers with 4 guys who were really interested to hear more about it.</div>
<div>Many of them HAD heard about D, but immediately wrote it off, like C#.</div><div>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.</div>
</div></div></div>