Official compiler

[Radu via Digitalmars-d]

On Thursday, 18 February 2016 at 11:47:48 UTC, Kai Nacke wrote:
> On Thursday, 18 February 2016 at 11:12:57 UTC, Jonathan M Davis 
> wrote:
>> If anything, the problem is probably that the gdc and ldc 
>> folks could use more help, but dmd and Phobos suffer from that 
>> problem on some level as well, albeit probably not as acutely.
>>
>> - Jonathan M Davis
>
> Yes, participation is a key issue for all compilers and the 
> libraries.
>
> It is easy to say that compilation speed of ldc may be fixed. 
> But turning on the profiler and looking for potential 
> improvements is a totally different action.
> As always I welcome every contribution to ldc. :-)
>
> Regards,
> Kai

As a casual user of the language I see that there is a 
fragmentation of resources and a waste in this regard with people 
developing in mainline, then some of you LDC guys catching up.

My simple assumption is that if presumably the dmd backend is not 
maintained anymore, a lot of the core dmd people can focus on 
improving whatever problems the frontend or glue layers have.

This could only mean that you core LDC guys could focus on llvm 
backend optimizations (both code gen and performance related). 
I'm going to assume that those kind of performance optimizations 
are also constantly done by upstream llvm, so more win here.

Users will not magically turn to contributors if their perception 
is that there is always going to be a catch-up game to play 
somewhere. Not to mention that if one want's to get something in 
LDC, one has to commit it in mainline, which is DMD, you just 
multiplied the know-how someone needs to have to do some useful 
work...

And finally, just pointing people to ldc/gdc (always a version or 
2 behind, another grief) each time dmd performance is poor, looks 
awfully wrong.