Required DMD changes for Mir and few thoughts about D future

[Johan Engelen via Digitalmars-d]

On Tuesday, 27 September 2016 at 10:44:28 UTC, Guillaume Piolat 
wrote:
> On Tuesday, 27 September 2016 at 01:17:16 UTC, Andrei 
> Alexandrescu wrote:
>> I'm not going to argue this much further. Essentially Mir is 
>> touted as a highly generic and portable library. Having it 
>> only work on one language implementation works against that 
>> statement, the credibility of Mir, and the credibility of D as 
>> an universal platform for creating fast code.
>
> Isn't it just a matter of adding "version(LDC)" around the more 
> optimized blocks?
> Having it work in DMD, however slower, is good enough.

(copying from the previous thread:)

I thought so too but if the algorithm is 50x slower, it probably 
means you can't develop that algorithm any more (I wouldn't). I 
think the common use-case for Mir is a calculation that takes 
seconds, so 50x turns a test into a run of several minutes, 
defeating the compilation speed advantage of DMD. The way I see 
it, faster development with Mir+DMD is not possible.

It is easy to want something, but someone else has to do it and 
live with it too. It's up to the Mir devs (**volunteers!**) to 
choose which compilers they support. As you can see from the PR 
that removed DMD support, the extra burden is substantial.
https://github.com/libmir/mir/pull/347

An extra subjective comment from recent experience: I think LDC 
has been very responsive to Mir's needs, thinking _with_ Mir 
development instead of fighting it and debating things to death. 
Imagine you are developing Mir, want to get something done, and 
then read the discussion starting here
https://forum.dlang.org/post/brieiuuuslpzfeioxuql@forum.dlang.org
The LDC PR with the requested functionality was submitted less 
than two weeks after
(pull was stalled because we don't control our own frontend).