D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)

[Joakim]

On Tuesday, 28 August 2018 at 13:39:40 UTC, Iain Buclaw wrote:
> On Thursday, 23 August 2018 at 15:35:45 UTC, Joakim wrote:
>> On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote:
>>> On Thursday, 23 August 2018 at 06:58:13 UTC, Joakim wrote:
>>>> On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh 
>>>> wrote:
>>>>> [...]
>>>>
>>>> Can you list what you or other Weka devs believe those fatal 
>>>> flaws to be? Because you've not listed any here, which makes 
>>>> you no better than some noob that comes in here, says D has 
>>>> to get better or it will die, then can't articulate what 
>>>> they mean by "better" or worse, mentions something trivial. 
>>>> Of course, you've actually used the language for years, so 
>>>> presumably you've got some real concerns, but do you really 
>>>> think the bug you just posted is "fatal" to the language?
>>>>
>>>> If you think there are fatal flaws, you might as well list 
>>>> them, whether technical or the development process, or you 
>>>> will just be ignored like any other noob who talks big and 
>>>> can't back it up. You may be ignored anyway, ;) but at least 
>>>> you'll have made a case that shows you know what you're 
>>>> talking about.
>>>
>>> I'd define fatal as some that can be fixed, but breaks 100% 
>>> of everyone's code, even if the change is net positive all 
>>> round.
>>>
>>> However how big a problem really is is in the eye of the 
>>> beholder. An example:
>>>
>>> Symptom: The compiler can't discard unused symbols at compile 
>>> time, and so it will spend a lot of time pointlessly 
>>> optimising code.
>>>
>>> Problem: D has no notion of symbol visibility.
>>>
>>> Possible Solution: Make all globals hidden by default unless 
>>> 'export'.
>>>
>>> Side effects: Everyone will be spending weeks to months 
>>> fixing their libraries in order to only mark what should be 
>>> visible outside the current compilation unit as 'export'.
>>>
>>> Benefits: Faster compile times, as in, in the most extreme 
>>> example I've built one project on github with gdc -O2 and 
>>> build time went from 120 seconds to just 3!
>>
>> So your example of a fatal flaw is that D could be 100X faster 
>> at compilation instead of just 10X than most every other 
>> native language out there?! C'mon.
>>
>
> But that's not true. D isn't a fast language to compile, dmd is 
> just a fast compiler.
>
> You may get a little leading edge with codebases that are 
> effectively C. Once you throw templates into the mix though, 
> your problems become exponential.
>
> Spending 4 seconds in the front end and codegen, only to wait 2 
> minutes in the optimizer is horrific.
>
> The alternative of discarding what seem to be unused symbols 
> only results in linker error of the obscure edge cases sort.
>
> Template emission strategy is a mess, we're better off just 
> instantiating all templates in all compilation units, and let 
> the compiler decide whatever to discard. Even -allinst does not 
> instantiate enough to allow the compiler to make such decisions 
> that C++ has no problem with (most of the time).

I think I've hit a variation of this problem before, where 
pulling in a single selective import in Phobos somewhere meant 
the entire module was compiled into the executable (though I 
suppose that could be a linker issue?):

https://forum.dlang.org/thread/gmjqfjoemwtvgqrtdsdr@forum.dlang.org

I guess this is why scoped/selective imports didn't help that 
much in disentangling Phobos. I figured it wasn't a big deal if 
it was just causing bigger executables, but even though I 
mentioned compilation speed there, I didn't think of how that's 
slowing down the compiler too, as you now note.

Pruning what's evaluated by the compiler based on 
scoped/selective imports, rather than apparently including the 
whole module, and getting D compilers to compile parallelized 
without separately invoking each module/package, ie a -j flag for 
the compiler when you invoke it with all your source at once, 
might be good projects for us to crowdfund, as discussed in this 
and my earlier Nim thread. Separate parallel compilation works 
wonders on my octa-core Android/AArch64 phone, where I mostly 
build D now, would be good to be able to combine that with 
invoking ldc with all source at once.