Official compiler

[Radu via Digitalmars-d]

On Thursday, 18 February 2016 at 12:23:18 UTC, Jonathan M Davis 
wrote:
> On Thursday, 18 February 2016 at 12:16:49 UTC, Radu wrote:
>> 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.
>
> That's what they're already doing. Very little work is done on 
> the backend (which is part of why it doesn't optimize as well 
> as gcc or llvm). Occasionally, work has to be done on the 
> backend, but by and large, the dmd devs are working on the 
> frontend, which benefits gdc and ldc just as much as it does 
> dmd. Now, that doesn't change the fact that the gdc and ldc 
> guys could use more help, but and if the dmd backend were 
> dropped, then presumably some of the work being done on the 
> frontend would be going to the glue layer for either gdc or 
> ldc, but that would further slow down the development of the 
> frontend and not necessarily improve things overall.
>
> Regardless, losing dmd's backend would be a _huge_ loss. Yes, 
> the binaries that it generates are slower, but its faster 
> compilation times are a huge win for developers and can 
> significantly improve the development time of a project. It 
> also has served us very well in impressing and attracting 
> programmers to D. Ultimately, we want all three compilers with 
> all three backends to be well-maintained and usable, because 
> they each have their pros and cons.
>
> - Jonathan M Davis

No to contradict what you said but there is still sensible work 
eating time, like Dwarf EH.

Probably making LDC part of the release process could make things 
better for both sides. I can see that after a while of sync 
releases someone will retire DMD for practical reasons.

Anecdotal evidence shows that each time D moved to a more open 
license or participation group things worked for the better.