Official compiler

[Radu via Digitalmars-d]

On Friday, 26 February 2016 at 11:01:46 UTC, Walter Bright wrote:
> On 2/26/2016 1:47 AM, Radu wrote:
>> Please don't get me wrong, we all apreciate what you offered 
>> to the D community,
>> but all these legal arguments are strongly tied to you, and 
>> less so to the
>> community.
>
> Didn't Google get hung out to dry over 6 lines of Java code or 
> something like that? And I don't know how long you've been 
> around here, but we DID have precisely these sorts of problems 
> during the Phobos/Tango rift. Ignoring licensing issues can 
> have ugly consequences.
>

I'm around here since 2004, not as vocal as I'm now, but yes, I 
remember those ugly times.
Due diligence is mandatory when dealing with software license, 
agreed, but we can't extrapolate your experience re. the backend 
with whatever is used in LDC or any other compiler. I'm sure in 
this regard LDC is not at peril.

>
>> Your LLVM license nit pick is hilarious, you can't do that 
>> when the "oficial" D
>> compiler has a non-liberal licensed backend, you just can't.
>
> That's not under my control, and is one of the reasons why D 
> gravitated towards the Boost license for everything we could.
>

Yes, agreed, boost FTW, but still doesn't solve the backend issue.

>
>> But setting things aside, we all need to acknowledge that the 
>> current setup is
>> not fair to motivated and proven third party compilers, their 
>> contributors, and
>> their users.
>
> I don't see anything unfair. gdc, ldc, and dmd are each as good 
> as their respective teams make them.
>

The lack of fairness comes from the way the ecosystem is setup, 
you have the reference compiler released, then everybody needs to 
catch up with it. Why not have others be part of the official 
release? This will undoubtedly increase the quality of the 
frontend and the glue layer, and probably the runtime, just 
because they will be tested on more architectures each release.

No matter how you put it, both LDC and GDC are limited in 
manpower, and also caught in the merge game with mainline. This 
is a bottle neck if they need to attract more talent. Right of 
the bat you need to do a lot of grunt work handling different 
repos, each at their own revision, plus all the knowledge about 
build env and testing env.

>
>> The D ecosistem must create and foster a friendly environment 
>> to anyone wanting
>> to have a good compiler that is current with the 
>> language/runtime/phobos
>> developments.
>
> And that's what we do. It's why we have 3 major compilers.

See above, just having 3 compilers (could be 5 for the matter), 
it's not enough. We will be better with just one that works 
great, but if that is not possible, at least give me the option 
to use the latest and greatest D on my Linux embedded ARM boards.