The Death of D. (Was Tango vs Phobos)

[Josh Szepietowski]

Sean Kelly Wrote:

> Yigal Chripun wrote:
> > Sean Kelly wrote:
> >  > I'd prefer being able to choose the GC I want without needing the
> >> compiler vendor to supply it.  Otherwise, the compiler vendor either
> >> needs to know how to write a GC (unlikely) or they need to bundle a
> >> third-party GC.  Also, different applications have different memory
> >> requirements.  Tango allows the GC to be chosen at link-time, which
> >> allows for a great deal of flexibility. 
> > 
> > If we compare to Java than Sun provides more than one GC with its
> > runtime and you can get even more specialized version GC if you really
> > need it (real-time for example). I guess there's nothing wrong in
> > getting a third party GC either.
> > The point is that in Java those GCs are chosen by the runtime (you can
> > specify if you run your app as a server or a client app and based on
> > that the GC is chosen) or you can specify explicitly your GC too, I
> > guess. Non of that should affect your code (unless you choose to use
> > specific extensions to the GC API provided but a specialized GC).
> > So, the choice of a GC doesn't affect your code.
> 
> It shouldn't, or there would be little point in supporting swappable GCs.
> 
> >>> The benefit is that the vendors will compete for runtime performance
> >>> which is good for the end user. I can choose vendor A's GC since it is
> >>> more efficient with regards to memory (if I care for that) or vendor B's
> >>> GC if it's faster, etc..
> >> Better to choose the GC separately from the compiler, then, so you can
> >> use the best of breed of each.
> >>
> >>> All I care is that everything that is visible to the end user is
> >>> standardized - i.e. I can do GC.collect() in my code since it's in the
> >>> APIs and don't care if I use llvmdc, dil, dmd, gdc, etc.. ( I'll care
> >>> for performance reasons and such of course and for that I can just
> >>> switch to a different vendor without any code changes)
> >> This is a standard library issue not a compiler runtime or GC issue.
> > 
> > it is an issue with the compiler runtime/GC if there isn't a standard
> > API and when I change my GC/runtime I need to edit the source.
> 
> Fortunately, Tango provides such a "standard API" so no source changes 
> are needed unless you do something like drop in a "GC" that simply calls 
> malloc and free, in which case your app will leak if it isn't written 
> with this in mind.
> 
> 
> Sean

Just wanted to voice that being able to overload the GC functions as in the D Conference 2007 talk is kind of a killer feature for me. Whatever shakedown happens from the phobos/tango runtime unificiation (which IMHO should be the first priority for the D 'standard library community') I really hope the swappable GC functions stay.