I'd be really interested to hear a comparison of those from someone experienced with D and its community.
- DMD is by far the D compiler with the shortest compile time. It's actually so fast that it comes with a utility, 'rdmd', which compiles-then-execute a D program. Say goodbye to shell/perl/python scripts, now you can have compile-time checks without an explicit/slow compilation step. We use it for automation tasks.
- GDC is the compiler of choice when it comes to supporting multiple targets and cross-compilation. It closely follows GCC and G++ command line conventions, meaning that using a single properly written Makefile it's easy to target x86/x86_64/arm, GNU/Linux (or Windows, but the mingw support has been in statis for years). Debian comes with pre-compiled arm-targetting GDC compiler. gdb, gcov, and operf work well. The generated code is fast (more than LDC), we use it for heavy computation tasks.
> GDC is the compiler of choice when it comes to supporting multiple targets and cross-compilation.
That entirely depends on what your targets are. GDC has some claim to "support" more architectures than LDC in that it can generate code that interfaces with C for just about every target GCC implements. However, this is only part of the story – "support" is a dangerous word to use here, as full-blown D runtime support is much more limited.
If you look at the most common platforms for desktop and mobile applications, LDC is definitely in the lead – in particular, LDC targets Windows/x86 (both 32 and 64 bit), macOS, iOS and Android/ARM, neither of which GDC supports. Some other platforms like AArch64 or PPC64 are beta quality on LDC, but have not received significant work on GDC. Both compilers support Linux/ARM (but admittedly GDC might be a bit more stable there).
> The generated code is fast (more than LDC)
[citation needed] This doesn't match my experience. More often than not, GDC and LDC are pretty much head to head, apart from small differences either way from the different backends (GCC vs. LLVM). In addition, LDC can benefit from some (minor) D-specific additions to the backend optimizer and some target-specific standard library optimizations, though, and sometimes has performance fixes that have not landed in GDC yet.
weka.io (one of the biggest D deployments, high-performance software-defined storage) and the Mir numerics library (very competitive performance numbers) both use LDC. If you have a real-world example where GDC generates significantly better code than LDC, please consider reporting it on the LDC issue tracker so we can look into fixing it.
Right. See:
http://www.infognition.com/blog/2014/d_as_scripting_language...
Also of interest:
Why D?
http://www.infognition.com/blog/2014/why_d.html
Both pages down right now, maybe the site is down, but have read those pages earlier. Google cache or archive.org may also work. Infognition is a software product company (video and related products) that does a good amount of their work in D. No connection them, just saw the site while browsing for D info earlier.
-iOS? -Android? -Windows?
Android: Experimental https://wiki.dlang.org/Build_LDC_for_Android
Windows: Works. Here is the Visual Studio Integration https://github.com/dlang/visuald
Lacking a bit wrapping of system and gui calls but for android see dlangui and Jni is not so bad.
It's very practical to write libraries in D. Possible to write whole apps, but I wouldn't start there for now.
LDC compiles to fast code and only slightly lags behind the reference. It might even catch up soon.
GDC compiles to fast code and supports many architectures in theory. It lags behind the most and architecture support also requires a ported runtime.
http://dlang.org/download.html
More information on the wiki (also linked to from the download page):