The Death of D. (Was Tango vs Phobos)

[Yigal Chripun]

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