Why is D unpopular?

[Don Allen]

Others have spoken in this long thread about why D is not more 
popular than X, where X=Go or Rust or what have you. I don't have 
much to add to this, other than to observe that Nim is good work 
and hasn't exactly taken over the world and, like D, it doesn't 
have a major corporate sponsor.

I can only speak from my personal experience. I'm in the process 
of completing a project to port about 9000 lines of C I wrote 10 
years ago to provide me with tools to manage my finances the way 
I want to. I'm a very experienced software developer and project 
manager, now retired. I'm certainly out-of-touch with the way 
programmers work today, but I am very familiar with contemporary 
languages as a result of this project, as well as a  
long-standing personal interest in programming languages.

As I observed in another recent post, I considered and rejected 
Rust, Go, Scheme, Haskell and Nim for this project and chose D. A 
few comments on each:

1. The main application of my project makes heavy use of gtk and 
sqlite. In Rust, gtk callbacks are required to be "static", 
meaning that the closures you pass to the signal connection 
routines must not make any free-variable references that are not 
static (don't live as long as the program). I will spare you the 
details, but if you are using sqlite in those callbacks, a 
necessity (all the work is done in the callbacks), I contend that 
there is no way to avoid using "unsafe" Rust code. The Rust 
community, like D's, is helpful, and I've discussed the specifics 
with them in gory detail, and no one has come up with a solution 
to the problems I've encountered, nor have I and believe me, I 
tried. If I am going to be forced to write unsafe Rust, why put 
up with all the borrow-checker, lifetime-checker pain? Rust's 
goal of memory safety without a GC makes we the programmers part 
of the memory management system. Add to that very long 
compilation times right in the middle of your edit, compile, 
debug cycle and it's just not worth it.

2. Scheme is a great language and Chez Scheme is a fine 
implementation. It's mature, well documented and very fast. I use 
Scheme for a lot of things. But this project is large enough that 
the dynamic typing becomes a liability. Too many issues that 
would be caught at compile time with a static language turn into 
run-time debugging adventures. There is also an issue with weak 
type-checking across the foreign-function interface (e.g., all 
pointers look like void* pointers to Chez, so you can pass the 
wrong one to C without complaint from the Chez or C compiler).

3. I could have done this project in Go and I'm sure it would 
have been fine, but I chose D instead based on my preference for 
the language. The tradeoffs weren't all that different so it came 
down to personal preference.

4. I can say the same about Nim -- personal preference. And there 
is a fair amount chatter about compiler bugs on the network that 
was also a bit off-putting.

5. Haskell is another great language, but the nature of how gtk 
works forces you into maintaining a fair amount of state the 
old-fashioned way, rather than passing new state with function 
calls. If much of your code is going to be old-fashioned 
imperative, why choose a functional language that has had 
imperative capabilities glued on?

This brings me to my D experience. It took me a while to learn 
where the land-mines are. The big one was passing a pointer to C 
that originated on the D side and then getting burned by the GC 
because I hadn't retained a reference to the object. It took a 
long time to debug that one, with help from this community. In 
hindsight, it would have been a lot simpler if I'd read the 
warning in the toStringz documentation that spells this out. 
Someone in this thread said that the GC makes C interaction 
difficult (I forget the exact phrase used). Nah -- you just need 
to know about this issue and take care to protect objects that 
originate on the D side. If they originate on the C side, no 
problem.

But once I got comfortable with the language, the porting of the 
C code went fairly quickly and the result is just what I wanted: 
much more concise, readable (and therefore maintainable) code the 
performance of which is indistinguishable from the C version 
(truth be told, most of the heavy lifting is done in sqlite, so I 
probably could have written this in Python -- ugh -- and gotten 
acceptable performance). I like being able to debug with gdb when 
runtime problems do arise and I appreciate the fast compile 
times. After all, the edit-compile-debug cycle is the inner loop 
when you are developing.

Overall, I'm very impressed by D. The compiler seems solid, the 
library functions I've used have all worked properly, and the 
documentation is mostly good. I think the criticisms that have 
been directed at D about lacking vision, blah, blah, have been 
from those who have not used it to produce working software that 
does what it is supposed to do with good performance. In other 
words, usable in practice (recall that Einstein said "In theory, 
there's no difference between theory and practice"). That is the 
ultimate test and at least for me, D has passed that test.

/Don