Things that keep D from evolving?

[Matt Elkins via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote:
> There are several reasons I want to use D rather than C# / Go / 
> something else:

I will focus on comparing against C++, because that has been my 
favorite general purpose language for a long time. While I often 
have to use C, Java, C#, etc. for various business reasons, when 
faced with the choice on pure technical merits I will go for C++ 
any day (haven't tried Go, but was unimpressed by my initial 
read-over). D is the first language I have ever encountered with 
a serious chance of unseating C++ as my personal favorite.

> - Interfacing with native API without jumping through hoops

Concur. Though I get this with C++, too.

> - Incredibly high abstraction and meta-programming 
> possibilities with relatively easier syntax + semantics.

Yes. The lack of powerful meta-programming is so frustrating in 
languages like Java and C#. C++ and D both have the power, but 
only D has the ease of reading and writing.

> - It's harder to reverse engineer native code than byte code 
> equivalent.

Meh. True, but this doesn't do much for me; it still isn't -that- 
hard to reverse native code, at least to the point of 
exploitation (to the point of copying is much harder). It just 
takes longer.

> - Trading off anything according to your needs.

Yes. This is critical. I actually feel like D does this a little 
worse than C++ (though not significantly so), if only because it 
is difficult to completely avoid the GC, and if you want to avoid 
it and still use inheritance you need to break out the custom 
allocators. Most of the time this isn't a problem.

> - Expressiveness and purity, immutablity concepts.

Expressiveness is key, though I haven't found D to be terribly 
more expressive than C++. A little better here, a little worse 
there. On the other hand, it is usually syntactically nicer when 
expressing concepts, sometimes greatly so.

Immutability is nice. The attention paid to threading was what 
caused me to take a closer look at D in the first place.

> - Having GC (but not a horribly slow one)

Meh. I know there are things which are much easier to express 
with a GC, but they don't really come up for me. On the other 
hand, I often need deterministic cleanup, so the GC can be kind 
of an annoyance, since it lends itself to a lot of wrapping 
things in structs and forcing me to pay more attention to 
lifetime rules than I have to in C++.

The other (main?) purported benefits of a GC (avoiding leaks and 
dangling pointers) don't do much for me, since it is almost 
trivially easy to avoid those problems in C++ anyway, without 
introducing the headaches of the GC; certainly it is easier than 
the focus I have to give D object lifetimes now. That may be a 
matter of relative practice, though, since I've used C++ for a 
long long time and D for...3 weeks? :)

> - Syntactic sugars (associtive arrays, powerful foreach, 
> slices...)

I'm still adjusting to the idea of AAs as part of the language 
rather than library. Not sure I like it, but on the other hand it 
doesn't really hurt. The foreach construct isn't any better (or 
worse) than C++'s, unless I'm missing something (which is very 
possible). But slices are awesome!

> - Compile times

Oh god yes. This makes metaprogramming so much more palatable.

> - Not bound to a specific platform (unlike C#, easier to do 
> cross-platform work in many cases)

I'll go it one step further, and note that D feels more portable 
than C++ to me...at least to the major platforms I usually work 
on. Maybe it's the simple fact that things like sockets are 
defined in the libraries, or that I don't have to #include 
<Windows.h> :).

> I wish D could be better. I really want it with all of my 
> heart...

D has a lot to offer. Here are a few other things I've really 
liked over C++:
* Modules. C++ is supposed(?) to get them at some point I 
suppose, but for here and now it's a clear advantage for D.
* Not syntactically separating interface and implementation 
(e.g., C++'s header vs source file dichotomy). This was never a 
true separation in C++, and just led to lots of extra syntax and 
minor DRY violations. Of course you could write everything inline 
anyway...until it depended on something declared later.
* Related to the point above, not having to think about whether 
to make something inline. Sure, C++ compilers make that choice 
for you, but you still have to decide whether to allow them (or 
at least the ones without link-time code generation) by putting 
your source in the header file. Needless headache for something a 
compiler can do.
* Properly doing away with the C preprocessor. I haven't seen a 
need for it that wasn't addressed by another D feature.
* Properly doing away with MI. Unlike some languages which just 
canned it, D actually replaced its functionality with other 
features.
* Thread-local by default. So simple. So useful.
* The in keyword. This is nice syntactic sugar over having a 
special trait in C++ which deduces whether to pass by value or 
const-reference. "foo(in bar)" is way more readable than 
something like "foo(traits<bar>::fast_param bar)"
* Convenient operator overloading for numerical types.
* @property. This little feature has been invaluable in porting 
my C++ code, letting me shave off tons of accessors and mutators 
that existed only for the sake of possibly being needed in the 
future. I didn't even need to use @property for this; its simple 
existence did the work for me!

There are others. Lots of others. Basically they boil down to: D 
mostly feels like C++, but just easier to read and write. Which 
is fantastic!

Of course, it's not all rosy. There has been some debate on the 
General forum about D's ability to express move semantics. I'm 
wary of the GC. Some language behaviors seem unintuitive (which 
can lead to bugs), like how you can store keys in AA that are 
null. And probably the biggest thing I don't like about D isn't 
the language design, but the immaturity of DMD. I've only used D 
for a few weeks, and I've already reported three bugs against it. 
This means that unlike with most languages, I don't have 
confidence that program failures are really my fault as opposed 
to just another compiler bug.

Summary: D has a lot of potential. With a little maturation, it 
could be a serious rival to C++.

Oh, and for whatever it's worth, I'm all for breaking changes if 
they improve the language. C++ has long suffered from 
unwillingness to do this. With a proper deprecation path, it can 
be a palatable way to continue evolving the language and avoiding 
stagnation.