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).
