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.
