On Friday, 28 November 2014 at 19:59:40 UTC, Xinok wrote:
> Given that we have GDC with the GCC backend and LDC with the LLVM backend, what are the benefits of keeping the DMD compiler backend? It seems to me that GCC and LLVM are far more developed and better supported by their respective communities. They have superior optimizers and are better equipped for migrating D to new platforms. On the other hand, from what I gather, there's lots of work to be done on DMD on improving support for x64 Windows and ARM.
>
> It's a genuine question, which is why I posted this to D.learn. I don't follow development on the backend and overall I'm unfamiliar with compilers, so I'm not sure what the benefits are of the D community continuing to maintain it's own backend.

As others have said already, the reasons why I use dmd are:

1. short compilation times which is important when coding both big projects and little test programs (i.e. fast prototyping). Nothing more annoying than having to wait for "ages" after you've made a few minor changes to your code.

From a PR point of view, this is important, because it gives D an advantage over other compiled languages and defeats the argument that scripting languages like Python don't have long compilation times.

2. dmd works out of the box on all supported OSes. You download it and are basically ready to go. GDC and LDC require a bit more work in this respect, especially on Windows (which can be a deal breaker for newcomers who are curious about the language).

As for the speed, I think that dmd is not too bad in most cases. I have a project I wanted to compile with LDC or GDC for the release build, but didn't, because the dmd version is already very responsive. So I decided to leave well enough alone (at least for now).

The thing about ARM is admittedly a chagrin in the behind. But what can you do.

Chris:

> As others have said already, the reasons why I use dmd are:

Walter has developed the back-end of DMD and he wants to keep using it no matter what. But I love the very small compilation time of dmd sources.

Bye,
bearophile

On Tuesday, 2 December 2014 at 10:37:18 UTC, bearophile wrote:
> Chris:
>
>> As others have said already, the reasons why I use dmd are:
>
> Walter has developed the back-end of DMD and he wants to keep using it no matter what. But I love the very small compilation time of dmd sources.
>
> Bye,
> bearophile

What I was trying to say is that I would be very disappointed if we didn't have the dmd backend anymore. It would be a real pain in the backend.

It's only words.
If we speak about LDC it can compile fast in debug mode with performance average to DMD's backend but with much great performance in release mode thanks to vectorization and other techniques.
Also LDC thanks to LLVM supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore platforms. And what about DMD? Only x86 and x86-64.

Just link LLVM statically with LDC and LDC will work out of the box as DMD. No problems at both Windows and Linux.

On Tuesday, 2 December 2014 at 10:57:20 UTC, Temtaime wrote:
> It's only words.
> If we speak about LDC it can compile fast in debug mode with performance average to DMD's backend but with much great performance in release mode thanks to vectorization and other techniques.
> Also LDC thanks to LLVM supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore platforms. And what about DMD? Only x86 and x86-64.
>
> Just link LLVM statically with LDC and LDC will work out of the box as DMD. No problems at both Windows and Linux.

That's good to hear. I never opposed to LDC nor GCD. In fact, LDC has the much needed support for other architectures. But the fact remains that dmd is a nice-to-have tool that works out of the box, and I don't see why there shouldn't be a dmd backend only because we have two other compilers. It always sounds as if a dmd backend somehow "harmed" the other two compilers.

Also, one has to set up the LLVM infrastructure etc., which is an extra step, unless LLVM works out of the box on Windows, which I might not be aware right now.

Setting up LLVM infrastructure is only needed when you is a LDC developer.
I think for ordinary users it's not their business.

On Sunday, 30 November 2014 at 02:07:16 UTC, ketmar via Digitalmars-d-learn wrote:
> On Sat, 29 Nov 2014 22:57:52 -0300
> Ary Borenszweig via Digitalmars-d-learn
> <digitalmars-d-learn@puremagic.com> wrote:
>
>> > besides, i don't want to use anything llvm-related.
>> Why not?
> let's say that there is some "ideological" reasons.

but do you use anything gpl-related?

On Wed, 03 Dec 2014 01:48:53 +0000
MachineCode via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> On Sunday, 30 November 2014 at 02:07:16 UTC, ketmar via Digitalmars-d-learn wrote:
> > On Sat, 29 Nov 2014 22:57:52 -0300
> > Ary Borenszweig via Digitalmars-d-learn
> > <digitalmars-d-learn@puremagic.com> wrote:
> >
> >> > besides, i don't want to use anything llvm-related.
> >> Why not?
> > let's say that there is some "ideological" reasons.
> 
> but do you use anything gpl-related?
that is exactly the reason i'm against LLVM: it's license. i believe that compiler and compiler construction tools must be [L]GPLed or proprietary, but not MITed/BSDLed/SIMILARed.

On Wed, Dec 3, 2014 at 8:03 AM, ketmar via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:
>
> that is exactly the reason i'm against LLVM: it's license. i believe that compiler and compiler construction tools must be [L]GPLed or proprietary, but not MITed/BSDLed/SIMILARed.

Heh -- fine for whatever compiler tools *you* create, but if someone else creates it, and is willing to distribute it under a more liberal license, why should you find it unacceptable, I'm not sure!

Isn't LGPL largely the same way versus the GPL?

And I'm pretty sure I read somewhere that even the Linux kernel code (or most big popular L/GPL libs like Qt) has some BSD-licensed stuff inside it...

BTW isn't Phobos Boost-licensed? And that's almost the same as BSD/MIT/ISC terms?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

On Wed, 3 Dec 2014 08:14:53 +0530
Shriramana Sharma via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com> wrote:

> Heh -- fine for whatever compiler tools *you* create, but if someone else creates it, and is willing to distribute it under a more liberal license, why should you find it unacceptable, I'm not sure!
'cause BSDL-likes allows proprietary forks. i don't trust proprietary vendors and i don't want 'em to create slightly incompatible closed fork which is "better". they have either do all the work by themselves and release proprietary product from the start, or have no legal way to fork and close the work of the other people.

i'm not against BSDL-likes per se, the only things i don't want with such licenses are compiler tools. so i'm not using LLVM-based compilers, i'm not interested in LLVM-based compilers, and such compilers are pretty much non-existant in my world.