The Death of D. (Was Tango vs Phobos)

[Sean Kelly]

Yigal Chripun wrote:
> Lars Ivar Igesund wrote:
>> Yigal Chripun wrote:
>>
>>> Lars Ivar Igesund wrote:
>>>> Lutger wrote:
>>>>
>>>>> Lars Ivar Igesund wrote:
>>>>>
>>>>>> Steven Schveighoffer wrote:
>>>>>>  
>>>>>>> This is my view (might not work, but I think it could).  For purposes
>>>>>>> of simplicity, I'll assume Walter currently develops the Phobos
>>>>>>> runtime (not that he doesn't, but I'm really not sure :).
>>>>>>>
>>>>>>> Maintenance of the merged runtime would become Walter's
>>>>>>> responsibility, with your help if necessary (ideas and help
>>>>>>> understanding, and enhancements if
>>>>>>> you wish).  Any changes desired for the runtime would go through
>>>>>>> Phobos (and
>>>>>>> Walter).  The Tango lib would use the now tango-fied Phobos runtime,
>>>>>>> with alias imports for existing code (e.g. tango.core.Thread would
>>>>>>> either publicly import std.thread or would privately import it, and
>>>>>>> alias the Thread class).
>>>>>> Based on historical evidence, this doesn't sound like a particularly
>>>>>> good idea. The current situation ensued for a reason.
>>>>>>
>>>>>> Also, I find that this discussion quite completely ignores the fact
>>>>>> that DMD is not the only D compiler anymore, and Walter is not the only
>>>>>> one with a vested interest in the functionality. In fact it looks like
>>>>>> quite many of the Tango conference attendants wants to discuss the
>>>>>> runtime.
>>>>> How does it ignore it? It sounds rather like the opposite to me: the
>>>>> very existence of multiple runtimes and the vested interest in those
>>>>> runtimes (Tango's primarily) are the key reason for unification.
>>>> Unification, yes. You misunderstood my point, which is that the runtime
>>>> implementation (not the compiler specific portion and direct language
>>>> support) should, IMO, be independent. As long as Walter/DigitalMars is
>>>> the developer of the language itself, it will be natural that eventual
>>>> new features that the language requires from the runtime, will be
>>>> bootstrapped by code from Walter, but I think Sean's work on the runtime
>>>> in Tango shows that such initial implementation can have large potential
>>>> for improvements.
>>>>
>>>>>  
>>>>>> If there should be a common-common (not only "just" compatible)
>>>>>> runtime, it shouldn't be controlled by one compiler vendor. Note that
>>>>>> the Tango runtime consists of 3 parts, where only one is compiler
>>>>>> specific. That particular part should probably be controlled/reviewed
>>>>>> by the compiler vendor, the rest (GC, threading, other things) should
>>>>>> be independent.
>>>>> I'll admit my understanding is limited, but I'd guess that will lead to
>>>>> even further fragmentation and non-portability.
>>>> The compiler part would have to conform to the necessary interfaces, of
>>>> course, but at some level the implementation details needs to be, and not
>>>> all can be kept in the compiler itself, thus it must be somewhere in the
>>>> runtime. I don't see this as a problem, just a necessary evil.
>>>>
>>> I don't understand your point. are you suggesting that things like the
>>> GC will be independent from the compiler?
>>> It seems to me that the model suggested by Sean is the way to go:
>>> ie:
>>>
>>> my code
>>> ----------
>>> standard library user code and standardized APIs to the runtime
>>> (threading, etc
>>> ---------------------------------
>>> compiler + runtime A  | compiler + runtime B | .....
>>>
>>>
>>> if a user isn't satisfied by runtime/compiler A he should just switch
>>> vendors.
>>> All the user facing APIs are standardized in the stdlib so all is needed
>>> is to recompile..
>> A common interface (API and ABI) would make this easier, but I just tend to
>> think that a common implementation as long as possible would be even
>> better - unification of efforts etc.
>>
> What's important to the end user IMHO is the API and ABI. having one
> unified GC implementation (for example) independent of a specific vendor
>  will remove some work from the compiler vendor but Id think this is
> rather a bad thing. I prefer each vendor to provide his own GC
> implementation (keeping with my example) which of course conforms to the
>  standards (API, ABI, ...) so that I can change to a different vendor
> easily without any changes to my code (all I need to do is recompile).

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.

> 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.


Sean