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