Reddit: why aren't people using D?

[Ary Borenszweig]

Michiel Helvensteijn escribió:
> Here's the opinion of an 'outsider'. I've experimented a bit with D in the
> past (years ago), but have lately just followed the newsgroup out of
> general interest.
> 
> I respect the expertise and hard work of the D team, but I won't use D. And
> here's an incomplete list of my reasons. I imagine there are other
> programmers who share my views. Most of these issues, if not all, are well
> known here. But I'll mention them anyway.
> 
> Please forgive (and correct) any factual mistakes. I'm sure there will be
> some. If you reply to any point in the list, I'll be glad to elaborate.
> 
> D offers too many ways to do the same thing:
> 
> * const, enum, immutable, invariant

Agree.

> * structs, classes

Don't agree. It's nice to have this distinction when you care about 
performance. I just removed a class from a Java project and replaced it 
with a pair of parameters because too many instances of it were created. 
If I had structs in Java I woudln't have that problem. C# also has them 
and it's ok.

> * functions, delegates, lazy parameter evaluation
> * garbage collection, manual D memory management, manual C memory management

It's ok if you want to have finer control over the memory. Not 
everything is high-level.

> 
> Even with so many ways to ensure const correctness, it is still possible to
> cast constness away, either making it impossible for the compiler to make
> any assumptions regarding constness, or making it very dangerous to do the
> cast.
> 
> D offers some cool features, but leaves them very underpowered:
> 
> 1. Contract programming (no contract inheritance, no compile-time static
> analysis, no loop invariants / ranking functions)
> 2. Class/Struct properties (no control over their use by class designer, no
> way to use +=, -=, no global properties, no parameterized properties)
> 3. Operator overloading (no fine control over comparison operators, fixed
> commutativity, confusing rule priority to determine translation, no
> overloading of !, &&, ||, <>=)
> 4. Tuples (no dedicated syntax, no parallel assignment, no non-flattening
> tuples without workarounds, no returning tuples)
> 5. Unit testing (not at compile time, not possible to categorize)
> 
> 6. There are two competing standard libraries for D. This has been discussed to
> death and I won't go further into it. But it's a bad thing.

It's amazing how many times 2, 5 and 6 were mentioned in this newsgroup. 
However nothing is done in this respect (maybe for 6 yes, but I think 
phobos should just dissapear).

> 
> I maintain that D suffers greatly from its lack of a formal specification.

For me, it's not the lack of a formal specification, but it's hard to 
find how something works. Navigating the site is a PITA.

> It is silly for a language as old and relatively popular as D to use a
> compiler written by a small group of people (1 person?) as the official
> reference to the language. Not only does the D specification feel really
> unstable, it has a very low bus-factor. In other words: if, hypothetically,
> Walter were hit by a bus, would the D language survive?
> 
> D just doesn't offer enough improvements over C++ to make it worthwhile
> switching over. Its design is not very adventurous, keeping simply too
> close to that of the C family, making it look like Yet Another C Language.
> I believe simply filling in the gaps of C++ wasn't enough to take over the
> world. There should have been a greater change.
>