Why do you continue to use D?

[Max Samukha]

On Friday, 5 June 2020 at 04:55:36 UTC, FeepingCreature wrote:
> 
>
> And because my new language project isn't ready yet. ;-)
>
> IMO, D is the worst best language. It simultaneously goes so 
> far in useful directions that it makes using any other C-like 
> painful, but still falls so far short of what it itself shows 
> is possible. (shared, immutable, copy constructors, the 
> half-working lifetime tracking, great templates with horrible 
> performance, mixin but no macros, ddoc but no introspection...) 
> I think that's the reason why D people keep wandering off to 
> make their own compilers. Lisp has somewhat the same property, 
> but there's less impetus to go off and make your own Lisp 
> because the base language is so very extensible.

Here is a concrete illustration of the above. Consider someone 
wants to accomplish a trivial code generation task:

void foo() {
   static foreach(i, ...) {
     static if (i == 3)
       outerDecl;
     localDecl;
     statement;
   }
}

Non-static foreach does not fit because of outerDecl. localDecl 
is problematic because 'static foreach' does not introduce local 
scopes. The poor programmer tries the most obvious:

{
    localDecl;
}

This does not work, because of the old bug 
https://issues.dlang.org/show_bug.cgi?id=3031, which was deemed 
not deserving a proper fix.

Next attempt - template mixin, which does introduce a special 
kind of scope:

void foo() {
   mixin template Local() {
     localDecl;
     statement;
   }
   static foreach (..)
     mixin Local;
}

This doesn't work because declaring mixin templates are not 
allowed inside functions. Work around by taking the mixin decl 
out of the function at the cost of cluttering the parent scope.

Then, the poor programmer is reminded that mixins cannot have 
statements. After a significant amount of cursing, the 
programmer, desperately trying to avoid the ugliness of string 
mixins and the inglorious lambda-statement hack, discovers this
https://github.com/dlang/dmd/pull/6760, reads the DIP and 
realizes that his issue should have been solved 3 years ago but 
was forgotten or deemed unimportant, who knows.

Of course, all this can be worked around with ugly hacks. 
However, if you multiply this experience by half the number of 
D's features, you will have the answer why people get frustrated.

I think the problem is that the designers of the features do not 
use them. Another problem is the "hardcore mechanical engineer" 
culture: if there's a working hack, no matter how ugly, use it 
and never look back.