Why D is not popular enough?

[Andrei Alexandrescu via Digitalmars-d]

On 8/12/16 6:58 PM, Steven Schveighoffer wrote:
> On 8/12/16 2:04 PM, Andrei Alexandrescu wrote:
>> On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
>>> On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
>>>>
>>>> Honestly, I don't think that shared is broken.
>>>
>>> Yes. It is broken.
>>>
>>> shared int x;
>>> ++x; // error, must use atomicOp.
>>> x = x + 1; // OK(!)
>>
>> How is this broken and how should it behave? -- Andrei
>>
>
> It's broken because it's inconsistent. If the compiler is going to
> complain about races in one case, but not in other equivalent cases,
> then the feature is useless.

But ++expr and expr1 = expr1 + expr2 are fundamentally different.

> If all I have to do to avoid compiler complaints is rewrite my
> expression in an equivalent way, then what is the point of the
> complaint? At that point, it's just a style guide.

A bunch of rewrites to seemingly identical behavior to avoid type errors 
are de rigoeur in so many situations. This is no different.

> What should it do? If I knew that, then I'd have proposed a DIP by now.
> It's not an easy problem to solve. I don't think you can "solve" races
> because the compiler can't see all interactions with data.

++expr contains a low-level race that is worth removing. Extending that 
to a variety of sub-patterns of expr1 = expr2 + expr3 seems a terrible 
idea to me.

> At first glance, it seems that shared data shouldn't be usable without
> some kind of explicit usage syntax. x = x + 1 is too innocuous looking.
> It's not going to "solve" the issue, but it makes the code easier to
> pick out.

We discussed this at a point (some 10 years ago). It was:

atomicReadRef(x) = atomicRead(x) + 1;

But it's painfully obvious that yes the intent is to read the address 
and read the thing... so why need these anyway? So we left things as 
they are.

I agree shared needs work, but this is not it. We're wasting our time here.


Andrei