On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
Are there any critical frameworks or libraries that are holding
you back in fully investing in D? Obviously I think D is an
awesome language, but some frameworks/libraries hold me back,
wish I could do everything in D.
1/ Debug support. It is truly bad. Does not work on OSX as far as
I know how, and works tediously on linux (line numbers are often
wrong in GDB and do not appear ins tack trace, need to use
specific linkers flags for this to work at all).
2/ Null reference types. Seriously. Everything is null by
default, you get an error where the pointer is used, not where
the problem is (and these 2 points can be fairly remote) and,
associated with 1) , hard to track. 99% of the time, the thing is
null due to a stupid mistake and the compiler could have catched
it.
3/ Templates error messages. Especially when you pass closures as
alias and the compiler decide to dump them with fucked up
indentation all in the middle of the error message. Probably good
for these that enjoy Klingon opera, but my taste differs.
4/ There used to be a fair amount of codegen bugs in closures,
but these seems mostly fixed at this stage. However, there is
still a lot of weirdness going on with them. Symbol in enclosing
scope will be resolved, but not alias this for instance.
Sometime, the closure will refuse to capture something for
unknown reasons and one need to rely on ugly hacks.
5/ mixins are not hygienic. It is often not possible to get the
symbols you are interested in at the site where they are going to
be resolved. For instance (toy example, but I have various real
world example of this in my code) :
module a;
struct S {}
import b;
MixinFail!S mf;
module b;
struct MixinFail(T) {
mixin(T.stringof ~ " t;");
}
This limitation, forces me jump through all kind of hoops, or
make various part of phobos unusable at even moderate scale (the
problem in already big in SDC, which is a bit more than 40 kLOC
at this stage).
6/ This is not a specific problem, but the general attitude that
consist in taking care of details without looking at the big
picture. Or to quote a coworker about "One will take great care
in a bakery to put presents cackes and sweets nicely, sell them
in a pretty box to customers, but do not care that there is a
dogshit on the pavement at the entrance".
The recent assert message thread is a good example of that. 6
pages in 2 days about how to best analyze the expression in the
assert to get a better error messages (the nice box), when we
don't even have line number in the trace that lead to this assert
(the dogshit).
