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/[email protected]
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.
