Is Anything Holding you back?

[deadalnix via Digitalmars-d]

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