Random points from a D n00b CTO

[uri via Digitalmars-d]

On Monday, 14 July 2014 at 06:13:38 UTC, Manu via Digitalmars-d 
wrote:
> On 14 July 2014 14:47, uri via Digitalmars-d 
> <digitalmars-d at puremagic.com>
> wrote:
>
>> On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:
>>
>>>
>>> - I was *very* disappointed that using base library locks you 
>>> into GC vs
>>> ref. counting.
>>> 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.
>>>
>>
>> This topic was bashed to death. There were compelling arguments
>> from both sides, but in the end no one pushing for ARC could
>> produce evidence that it was better than GC.
>>
>
> 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.
>
> 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.
> 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.
>
> 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.
>
> 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.
> 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.
>
> Currently there's a big push to remove hidden GC allocs from
>> Phobos, starting with @nogc.
>>
>> std.allocators is just around the corner as well, which will
>> provide a solid framework to build better allocation 
>> strategies.
>
>
> 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.
> 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.
> 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.
>
> 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.

All good points. Thanks and my bad for the misinformation, sorry.

uri