<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 14 July 2014 14:47, uri via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:</div>
<div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
- I was *very* disappointed that using base library locks you into GC vs ref. counting.<br>
Separate, I like how Objective C has NSObject for GC purpose(I'd love a framework that is just ref counting), but there should be dual libs and base should not be GC.<br>
</blockquote>
<br></div>
This topic was bashed to death. There were compelling arguments<br>
from both sides, but in the end no one pushing for ARC could<br>
produce evidence that it was better than GC.<br></blockquote><div><br></div><div>Andrei himself pushed such evidence in an interesting case study that explored a high-end ARC implementation. It compared impressively with 'the fastest GC's' (or some description very close to that). D's GC is certainly not among those in comparison, which suggested the paper's tech would probably be a win for D no matter how you look at it.</div>
<div><br></div><div>And the counter evidence is overwhelming. As many times as I've asked the experts for comment, I've still *NEVER* heard anybody disagree that D's GC will probably remain really bad for the indefinite future. Even the ones that are strongly in favour of GC; nobody seems to know how to do it, and many have said it's probably impossible.</div>
<div>Even if it was theoretically possible, that only solves one of numerous problems... Nobody has ever addressed the low-available-memory argument I've put forward a number of times, which is the standard operating environment of most embedded computers.</div>
<div><br></div><div><div>So, I don't feel like there was any such conclusion as you suggest. Personally, I just became horribly apathetic and gave up. My general participation and motivation in this community has declined significantly as a result.</div>
<div><br></div><div>I'm among the minority that REALLY care about this, and it's clear (and it's been made clear) that if I'm not prepared to work on it myself, then it won't move forward.</div><div>That's fine, and it's perfectly reasonable. But I'm not in the least bit interested in working on GC technology myself - I'm not an expert, and it's not a field that interests me, thus I decided to desist participating in discussions.</div>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Currently there's a big push to remove hidden GC allocs from<br>
Phobos, starting with @nogc.<br>
<br>
std.allocators is just around the corner as well, which will<br>
provide a solid framework to build better allocation strategies.</blockquote><div><br></div><div>We're yet to see how to use the allocators API to specify a replacement default allocator used by the languages intrinsic allocations, which makes it rather less exciting.</div>
<div>Anyone can invent an allocator interface, but designing it such that it can be used to configure the languages implicit allocations is much more complex. I'm concerned that Andrei's allocator interface doesn't actually address this... At least, I haven't seen any discussion about how it will.</div>
<div>That said, I'm not trying to down-play the importance of a standard allocator API, and Andrei's development is very important and appreciated, but I am yet to find out how it actually addresses any of my real concerns relating to allocation.</div>
<div><br></div><div>As I see it, I have zero concern about allocations I control. I am entirely concerned with intrinsic/implicit allocations that I don't, and may potentially (likely) originate from within 3rd party libraries.</div>
</div></div></div>