What are the worst parts of D?

[Andrei Alexandrescu via Digitalmars-d]

On 10/8/14, 4:17 AM, Don wrote:
> On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote:
>> More particulars would be definitely welcome. I should add that
>> Sociomantic has an interesting position: it's a 100% D shop so
>> interoperability is not a concern for them, and they did their own GC
>> so GC-related improvements are unlikely to make a large difference for
>> them. So "C++ and GC" is likely not to be high priority for them. --
>> Andrei
>
> Exactly. C++ support is of no interest at all, and GC is something we
> contribute to, rather than something we expect from the community.

That's awesome, thanks!

> Interestingly we don't even care much about libraries, we've done
> everything ourselves.
>
> So what do we care about? Mainly, we care about improving the core product.
>
> In general I think that in D we have always suffered from spreading
> ourselves too thin. We've always had a bunch of cool new features that
> don't actually work properly. Always, the focus shifts to something
> else, before the previous feature was finished.
>
> At Sociomantic, we've been successful in our industry using only the
> features of D1. We're restricted to using D's features from 2007!!
> Feature-wise, practically nothing from the last seven years has helped us!
>
> With something like C++ support, it's only going to win companies over
> when it is essentially complete. That means that working on it is a huge
> investment that doesn't start to pay for itself for a very long time. So
> although it's a great goal, with a huge potential payoff, I don't think
> that it should be consuming a whole lot of energy right now.
>
> And personally, I doubt that many companies would use D, even if with
> perfect C++ interop, if the toolchain stayed at the current level.

That speculation turns out to not be true for Facebook. My turn to 
speculate - many other companies have existing codebases in C++, so 
Sociomantic is "special".

> As I said in my Dconf 2013 talk -- I advocate a focus on Return On
> Investment.
> I'd love to see us chasing the easy wins.

That's of course good, but the reality is we're in a complicated 
trade-off space with "important", "urgent", "easy to do", "return on 
investment", "resource allocation" as axes. An example of the latter - 
ideally we'd put Walter on the more difficult tasks and others on the 
easy wins. Walter working on improving documentation might not be the 
best use of his time, although better documentation is an easy win.


Andrei