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
