DMD backend quality (Was: Re: DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion)

Seb seb at wilzba.ch
Thu Feb 20 06:34:45 UTC 2020


On Thursday, 20 February 2020 at 03:35:13 UTC, jxel wrote:
> On Thursday, 20 February 2020 at 01:54:45 UTC, H. S. Teoh wrote:
>> On Thu, Feb 20, 2020 at 01:11:08AM +0000, NaN via 
>> Digitalmars-d wrote:
>>> On Wednesday, 19 February 2020 at 19:36:38 UTC, bachmeier 
>>> wrote:
>> [...]
>>> > What does "dropping DMD" mean? Are you going to go around 
>>> > breaking kneecaps if you catch someone working on DMD? It's 
>>> > an open source project and people who want to work on it 
>>> > are going to work on it.
>>> 
>>> I assume "dropping DMD" just means making LDC the main 
>>> reference compiler instead of DMD.
>>> 
>>> It's not about forcing anyone to do anything, it's about 
>>> perception, for example new users will almost always start 
>>> with the official compiler. So you start to build more user 
>>> base around LDC, and over time, if the d core team is focused 
>>> in that direction, most people will follow suit.
>> [...]
>>
>> Good luck getting Walter to agree to abandoning DMD and 
>> working on LDC instead.
>>
>>
>> T
>
> No body expect him to. Just how the official DMD isn't built 
> with LDC, why there isn't a 64 bit version of DMD on Windows, 
> why Optlink is still even a thing, why restrictions are placed 
> in DMD to workaround an Optlink bug instead of fixing it. No 
> one expects these things to change. What seems like common 
> sense means nothing to someone stubborn and blinded by pride.

People often don't see how much effort is wasted on maintaining 
multiple compilers, but how much time i.e.
- the release process (especially with stable releases)
- keeping CIs up, configured and running
- actively triaging bugs
- having multiple test suite solutions
- maintaining automations (e.g. dlang-bot)

consumes is hidden to non-insiders. Furthermore,

- supporting every new feature in each backend (ask Ian or kinke 
about the recent multiple inner pointer change)
- maintaining multiple installers
- nasty DMD backend bugs (a few people apart from Walter actually 
do try to fix things in the backend)
- working around obscure infra problems (IIRC Digitalmars libc 
still isn't thread-safe and people have run in all kinds of 
problems with it and needed to come up with ingenious solutions, 
even DMD's build.d shows signs of this)
- working with Digitalmars Make
- maintaining a modern set of features per compiler (address 
sanitization, ...)
- keeping other compilers up-to-date with upstream (every release 
introduces regressions)
- maintaining support for every OS for every compiler 
(e.g.FreeBSD)
- having an n-times bigger surface for bugs
...

And I haven't even mentioned the bottleneck of any major DMD PR 
needing to be approved by Walter.

In my opinion DMD is only the default because switching 
development efforts to LDC would be a rather big initial cost 
(time investment) to setup/change the infrastructure and no one 
wants to head this effort.

> if the d core team is focused in that direction, most people 
> will follow suit.

I would switch in a heartbeat and I am fairly confident to 
estimate that the same applies to almost all remaining active 
contributors who haven't left yet because of frustration.



More information about the Digitalmars-d mailing list