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.
