December 23, 2016
On Wed, 2016-12-21 at 15:49 -0800, Jonathan M Davis via Digitalmars-d wrote:
> […]
> 
> Anyone who wants to use ldc can use ldc. It doesn't need to be the
> reference
> compiler for that. And unlike gdc, it's actually pretty close to dmd.
> So,
> there should be no problem with folks using ldc for production right
> now if
> they want to.

Strikes me that the really obvious thing to say is that DMD is the playground where whoever wants to can play with and progress the D front end in the knowledge that no-one is going to use DMD in production. People use LDC in production because it is the right thing to do: stable proven front end, stable proven backend, and yet up to date.

What is not to like here? What is the problem here?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

December 24, 2016
On 24/12/2016 3:14 AM, Russel Winder via Digitalmars-d wrote:
> On Wed, 2016-12-21 at 15:49 -0800, Jonathan M Davis via Digitalmars-d
> wrote:
>> […]
>>
>> Anyone who wants to use ldc can use ldc. It doesn't need to be the
>> reference
>> compiler for that. And unlike gdc, it's actually pretty close to dmd.
>> So,
>> there should be no problem with folks using ldc for production right
>> now if
>> they want to.
>
> Strikes me that the really obvious thing to say is that DMD is the
> playground where whoever wants to can play with and progress the D
> front end in the knowledge that no-one is going to use DMD in
> production. People use LDC in production because it is the right thing
> to do: stable proven front end, stable proven backend, and yet up to
> date.
>
> What is not to like here? What is the problem here?

Except dmd's backend is far more well proven then LLVM is.
So that argument needs to be tweaked a little bit.

December 23, 2016
On Friday, 23 December 2016 at 14:44:41 UTC, rikki cattermole wrote:
> On 24/12/2016 3:14 AM, Russel Winder via Digitalmars-d wrote:
>> On Wed, 2016-12-21 at 15:49 -0800, Jonathan M Davis via Digitalmars-d
>> wrote:
>>> […]
>>>
>>> Anyone who wants to use ldc can use ldc. It doesn't need to be the
>>> reference
>>> compiler for that. And unlike gdc, it's actually pretty close to dmd.
>>> So,
>>> there should be no problem with folks using ldc for production right
>>> now if
>>> they want to.
>>
>> Strikes me that the really obvious thing to say is that DMD is the
>> playground where whoever wants to can play with and progress the D
>> front end in the knowledge that no-one is going to use DMD in
>> production. People use LDC in production because it is the right thing
>> to do: stable proven front end, stable proven backend, and yet up to
>> date.
>>
>> What is not to like here? What is the problem here?
>
> Except dmd's backend is far more well proven then LLVM is.
> So that argument needs to be tweaked a little bit.

It is not true for Mir projects,  sometimes ICE occurs without any description while LDC just works. --Ilya

Bug report for ICEs requires to much efforts because code size should be reduced.
December 23, 2016
On Friday, 23 December 2016 at 15:02:23 UTC, Ilya Yaroshenko wrote:
> [...]
> It is not true for Mir projects,  sometimes ICE occurs without any description while LDC just works. --Ilya
>
> Bug report for ICEs requires to much efforts because code size should be reduced.

I found quite a few in LDC too ;-) In any case, Dustmite[1] helps to greatly reduce the time needed to create a minimal testcase to report as a bug, and the tool will soon be available as a Debian package as well (anything that doesn't use dub and is no library is rather easy to package).

[1]: https://github.com/CyberShadow/DustMite
December 23, 2016
On Friday, December 23, 2016 14:14:41 Russel Winder via Digitalmars-d wrote:
> On Wed, 2016-12-21 at 15:49 -0800, Jonathan M Davis via Digitalmars-d
>
> wrote:
> > […]
> >
> > Anyone who wants to use ldc can use ldc. It doesn't need to be the
> > reference
> > compiler for that. And unlike gdc, it's actually pretty close to dmd.
> > So,
> > there should be no problem with folks using ldc for production right
> > now if
> > they want to.
>
> Strikes me that the really obvious thing to say is that DMD is the playground where whoever wants to can play with and progress the D front end in the knowledge that no-one is going to use DMD in production. People use LDC in production because it is the right thing to do: stable proven front end, stable proven backend, and yet up to date.
>
> What is not to like here? What is the problem here?

dmd compiles code faster, which is better from a development standpoint. Assuming that dmd and ldc are compatible enough, it makes a lot of sense to do most of the development with dmd and produce the actual product with ldc. But if someone wants to use ldc for the whole thing because of FOSS concerns or personal preference or whatever, that's fine too. It's just not what I'd want to do if I could avoid it. dmd's compilation speed is worth a lot.

- Jonathan M Davis


December 23, 2016
On Thursday, 22 December 2016 at 12:15:06 UTC, Matthias Klumpp wrote:
> But the much more important point for us is support and maintainability. The reference compiler will have a much bigger development team and higher focus of attention.

Bugs in frontend, phobos and most of druntime currently go to DMD team. Bugs in LLVM backend go to LLVM team. The bug you had with atomicOp was trivial and was fixed in a day.

> Additionally, people learning D will told "use DMD" and won't find it in their distribution, which is annoying for them (they think D isn't well supported, while our LDC/GDC packages are less used).

That recommendation is probably already a mistake. One reason to recommend dmd is that it's recent, but this implies installation of the recent version; if people use packaged version, the recommendation is moot (and they again suffer from old docs and libs). Another reason is compilation speed and some people see it important, so to stop dmd recommendation you also need to kill dmd for good else it will still have speed advantage.

>> Confusing claim that he can't use dmd given that he says he uses it.
>
> Huh? Where is this stated?

> DMD being non-free also makes it incredibly hard to sell D in the FLOSS community. Because of that, I can not actually test my code with dmd
> which means that I don't benefit from improvements done in druntime, Phobos and other parts of D as quickly as others
(You don't benefit from recent improvements because you use a packaged version)
> When using dmd this is not an issue, since dmd is very fast
Ah, I probably misunderstood this as if you use dmd.
December 23, 2016
On 12/21/2016 5:30 PM, Andrei Alexandrescu wrote:
> Would be great to narrow this down regardless. Shouldn't be too difficult since
> the penalty is so huge. Must be a pathological case we should fix anyway. -- Andrei

Not a complete solution, but should help:

https://github.com/dlang/dmd/pull/6356
December 23, 2016
On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via Digitalmars-d wrote:
> […]
> 
> Except dmd's backend is far more well proven then LLVM is.

Come now that is obfuscation – you need to make good on this claim.

The LLVM backend has many, many more users than the DMD backend and the LLVM backend is used with many more different languages than the DMD backend. The LLVM backend is proven far more than the DMD backend simply on the basis of statistical likelihood.

I'll back LLVM any day in this argument.

> So that argument needs to be tweaked a little bit.

No it doesn't, it stands as stated.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

December 23, 2016
On Fri, 23 Dec 2016 07:59:40 -0800, Jonathan M Davis via Digitalmars-d wrote:
> dmd compiles code faster, which is better from a development standpoint. Assuming that dmd and ldc are compatible enough, it makes a lot of sense to do most of the development with dmd and produce the actual product with ldc.

You'll want your CI server to build with both thanks to ABI incompatibilities. That way, if I depend on a library that you wrote, I can grab an official build from the CI server that's ABI-compatible with DMD. Or do everything from source.
December 23, 2016
On Fri, 23 Dec 2016 18:29:15 +0000, Russel Winder via Digitalmars-d wrote:

> On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via Digitalmars-d wrote:
>> […]
>> 
>> Except dmd's backend is far more well proven then LLVM is.
> 
> Come now that is obfuscation – you need to make good on this claim.
> 
> The LLVM backend has many, many more users than the DMD backend and the LLVM backend is used with many more different languages than the DMD backend. The LLVM backend is proven far more than the DMD backend simply on the basis of statistical likelihood.

Plus the number of people on hand to fix errors in LLVM outweighs the number available to fix errors in the DigitalMars backend by a factor of several hundred.