Why D is not popular enough?

[Andrei Alexandrescu via Digitalmars-d]

On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:
> I'm also tempted to argue that making shared virtually unusable without
> casting it away would be a good idea

It's a bad idea, no two ways about it. The bummer here is that this is 
the only topic (and one where D gets it right) off of a whole list that 
Shachar gave, which I'll copy below. His slides are at 
http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improvement-opportunities. 
Is the talk video anywhere?

> - No RAII support, despite the fact everybody here seems to think that D supports RAII.

So that is slide 4. Could you please give a bit of detail?

> - Recursive const makes many cases where I can use const in C++ (and
> enjoy the protection it provides) simply mutable in D.

(It's transitive, not recursive.) Can't help much here but note that 
C++'s const being shallow is a source of confusion among beginning 
programmers. It's a matter in which reasonable people may disagree. I 
clearly see how someone used to C++'s const wold feel uncomfortable with 
D's.

> - This one I have not complained about yet. Operator overloads
> stepping on each other's toes. In my case, I have a container (with
> opIndex that accepts a custom type and opOpAssign!"~") and I place in
> it a struct with some operator overloads as well (have not reduced
> the cause yet, hence no previous complaint about this one). So, when
> I write
>
> Container[IndexType] ~= Type;
>
> And the compiler assumes that means:
> Container.opIndexOpAssign!"~"(IndexType, Type);
>
> but since nothing like that is defined, the code doesn't compile. I
> ended up writing (actual code from the Weka code base):
>
> blockIds[diskIdx].opOpAssign!"~"(makeBlockId(stripeIdx+i,
> placement.to!SlotIdx(diskIdx)));
>
> Took me almost ten minutes and consulting someone else to find this
> solution.

The opIndexOpAssign family is intentional and arguably a good thing. The 
semantics of std::map's operator[] are controversial and suboptimal; 
opIndexOpAssign is specially designed to allow efficient dictionaries 
and sparse arrays. If you get to reduce the code we'd definitely want to 
fix whatever bug is there.

> - GC. GC. GC. Some more GC.

You mean there's too much of it? We're on that.

> - Integral type operations promotion and the constant need for casts.

This is... funny coming from a self-proclaimed C++ lover. Anyhow, VRP 
has bugs that we need to fix.

> - No warning for signed/unsigned comparisons. An unfailing source for bugs.

This is actionable too.

> - No ref type.

This you need to live with.

We'd love to make the life easier for Weka, but you need to be careful 
when mixing things of the D ethos you don't like but won't change 
(qualifiers, ref) with things that we can improve.

Did you try the .d/.di compile-time table?


Andrei