Official compiler

[Jonathan M Davis via Digitalmars-d]

On Thursday, 18 February 2016 at 16:47:16 UTC, Márcio Martins 
wrote:
> On Thursday, 18 February 2016 at 15:36:42 UTC, Jonathan M Davis 
> wrote:
>> On Thursday, 18 February 2016 at 14:23:12 UTC, Márcio Martins 
>> wrote:
>>> I agree, but I don't see why this would have to change. It 
>>> shouldn't change. Frontend development could happen on DMD as 
>>> the *reference* compiler.
>>
>> And what exactly is the difference between the "official" 
>> compiler and the "reference" compiler supposed to be?
>>
>> - Jonathan M Davis
>
> "official" carries a connotation of endorsement doesn't it? In 
> other words, if you are given a choice of 3 and you know very 
> little about each, which would you predict would give you a 
> better user experience?
>
> Reference in this case is the one that most closely follows the 
> bleeding edge of the language spec, which new users don't 
> benefit a lot from. In this case it's also where all the 
> frontend development would happen. But what we call it this 
> doesn't really matter to end users.
>
> What I have been defending this far is that we could entertain 
> the possibility that end users could be better off if we 
> "suggested" they try out one of the other compilers before they 
> try DMD. The easiest way to suggest that is to stamp "official" 
> on one of the stronger alternatives. Once installers for LDC 
> and GDC are on par with DMD, is there still a pragmatic reason 
> to suggest DMD to new users? Given that all that DMD has going 
> for it from the perspective of a new user is the compilation 
> speed?
>
> For everyone else nothing would change, we'd go about our daily 
> lives, using our favorite compiler as always. But meanwhile, 
> people exploring and looking to try D could try out it's 
> amazing features and get proof in first-hand, that these 
> awesome features come at no efficiency cost, as advertised.

Honestly, I think that dmd _should_ be the goto compiler. It's 
the fast one. It's the most up-to-date - especially right now as 
gdc and ldc have been trying to get to the point that they're 
using the new D frontend instead of the C++ one. gdc and ldc are 
great if you want to make sure that you're code is faster in 
production, but they're slower for actually get the code written, 
and AFAIK, if you want to be writing scripts in D (which is 
really useful), you need rdmd, which means using dmd (and I sure 
wouldn't want those to be compiled with gdc or ldc anyway - 
compilation speed matters way more in that case than it even does 
during development).

New users are frequently impressed by how fast dmd compiles code, 
and it's a big selling point for us. It's only later that 
benchmarking comes into play, and if want to do that, then use 
gdc or ldc. The download page already says to use gdc or ldc if 
you want better optimization.

I wouldn't want to use gdc or ldc for normal development unless I 
had to, and I wouldn't want to encourage others to either. dmd's 
speed is worth way too much when it comes to getting actual work 
done. And it's not like it generates slow code. It just doesn't 
generate code that's as fast as gdc or ldc generates, and when 
you get to the point that you need the fast binary, then use gdc 
or ldc. But use them as the default? Why? dmd is a clear winner 
as far as development goes. It's both faster and more up-to-date. 
It's just that gdc or ldc would be better for production code if 
you really need all the speed that you can get.

We need to work towards getting and keeping gdc and ldc in sync 
with dmd so that they stop being behind like they typically are, 
and we do need to make sure that it's clear that gdc and ldc 
generate faster binaries. But I think that it would be a huge 
mistake to push either of them as the one that everyone should be 
using by default.

- Jonathan M Davis