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