Thoughts about D

[Walter Bright]

On 11/26/2017 4:14 PM, IM wrote:
> I'm a full-time C++ software engineer in Silicon Valley. I've been learning D 
> and using it in a couple of personal side projects for a few months now.

Great! Glad you're enjoying it and took the time to post your thoughts.


> - D is unnecessarily a huge language. I remember in DConf 2014, Scott Meyers 
> gave a talk about the last thing D needs, which is a guy like him writing a lot 
> of books covering the many subtleties of the language. However, it seems that 
> the D community went ahead and created exactly this language!

You'll find the same language in 2014 as today, it hasn't changed much. All 
languages (except C) in common use accrete features.

D does have some baggage that has been removed, like `typedef`, but on the whole 
whenever we try to remove something, someone always has built their store around it.

The good news, however, is just use the subset of D that works for you.


> - ‎D is very verbose. It requires a lot of typing. Look at how long 'immutable' 
> is. Very often that I find myself tagging my methods with something like 'final 
> override nothrow @safe @nogc ...' etc.

The idea is if you just want to write code, you can eschew using them (except 
'override'), and just write code. They're all used for optimization or to 
provide enforceable self-documentation. Other languages would require those to 
be documented in the comments, which is not enforceable and even more wordy :-)

'override' is as opposed to 'virtual' which C++ requires and D doesn't.


> - ‎It's quite clear that D was influenced a lot by Java at some point, which led 
> to borrowing (copying?) a lot of Java features that may not appeal to everyone.

That's true. Java looked like it was going to take over the world when D was 
young. These days I'd get rid of inner classes in favor of lambdas if I could, 
but you can just ignore inner classes.


> - ‎The amount of trickeries required to avoid the GC and do manual memory 
> management are not pleasant and counter productive. I feel they defeat any 
> productivity gains the language was supposed to offer.

That's true. But it's hard to beat GC for just writing code and getting it to 
run safely and without pointer bugs.


> - ‎The thread local storage, shared, and __gshared business is annoying and 
> doesn't seem to be well documented, even though it is unnatural to think about 
> (at least coming from other languages).

The idea with TLS is to deal with endemic threading bugs other languages have. 
The default in C/C++ is for globals to be shared, which is completely 
impractical to examine a large code base for. __gshared is meant to stand out 
and be greppable, making code much more auditable.


> - ‎D claims to be a language for productivity, but it slows down anyone thinking 
> about efficiency, performance, and careful design decisions. (choosing structs 
> vs classes, structs don't support hierarchy, use alias this, structs don't allow 
> default constructors {inconsistent - very annoying}, avoiding the GC, look up 
> that type to see if it's a struct or a class to decide how you may use it ... 
> etc. etc.).

D structs are value types, and classes are reference types. Everything flows 
from that. C++ structs and classes are the same thing, and can be used as both 
reference and value types at the same time, whether that works or not. I rarely 
find C++ classes with documentation saying if they are intended as a reference 
or value type, and the documentation won't prevent one from misusing it.

I'm not the only one to suggest that making the value/ref design decision is a 
pretty crucial one to make before designing the code. :-)


> I could add more, but I'm tired of typing. I hope that one day I will overcome 
> my frustrations as well as D becomes a better language that enables me to do 
> what I want easily without standing in my way.

Many people have difficulty with D when coming from, say, C++, because it does 
require a different way of thinking about code. This passes once one gains 
experience and comfort with D. After all, my early Fortran code looked just like 
BASIC, my C code looked like Fortran, my C++ code looked like "C with a few 
classes", and my D code looked a bit too much like C++ :-)

I have recently finished converting the Digital Mars C++ compiler front end from 
"C with classes" to D. Even though it is a rote line-by-line translation, it 
simply looks better in D (much less of a snarl). Over time, as I refactor bits 
of it, it'll steadily look better. I find it significantly easier to write good 
looking code in D, and it is less verbose than C++.

For some trivial examples,

     C++: unsigned long long
     D: ulong

     C++: template<typename T> struct S { ... };
     D: struct S(T) { ... }

     C++: for (int i = 0; i < 10; ++i)
     D: foreach (i; 0..10)

     C++: decltype
     D: auto