Official compiler

[Jonathan M Davis via Digitalmars-d]

On Thursday, 18 February 2016 at 20:28:41 UTC, David Nadlinger 
wrote:
> On Thursday, 18 February 2016 at 17:56:32 UTC, Jonathan M Davis 
> wrote:
>> […] if you want to be writing scripts in D (which is really 
>> useful), you need rdmd, which means using dmd
>
> You can use rdmd with ldmd2 just as well (and presumably gdmd 
> too).

Good to know.

> Clear only to somebody with x86-centric vision. I'm not 
> claiming that the somewhat lower compile times aren't good for 
> productivity. But being able to easily tap into the rich LLVM 
> ecosystem or even just targeting the most widely used CPU 
> architecture (in terms of units) is also something not to be 
> forgotten when considering the development process.

Having ldc is huge, but as long as you're targeting x86(_64) as 
one of your platforms, developing with dmd is going to be faster 
thanks to the fast compilation times. And if we can get dmd and 
ldc to be fully compatible like they should be, then as long as 
your code is cross-platform, it should be possible to develop it 
with dmd and then target whatever you want with ldc - though 
obviously some stuff will have to be done with ldc when it's 
something that dmd can't do (like a version block targeting ARM), 
and anything that's going to ultimately be released using ldc 
should be tested on it. But that fast compilation time is so 
tremendous in the edit-test-edit cycle, that I just can't see 
using ldc as the main compiler for development unless what you're 
doing isn't targeting x86(_64) at all, or ldc isn't compatible 
enough with dmd to do most of the development with dmd.

But assuming that dmd and gdc/ldc are compatible, I would 
definitely argue that the best way to do D development is to do 
most of the development with dmd and then switch to gdc or ldc 
for production. That way, you get the fast compilation times when 
you need it, and your final binary is better optimized.

- Jonathan M Davis