D has:

- fast compilation times

- a module system

- famously powerful metaprogramming and compile-time introspection

- a familiar, but not ugly syntax

- comes with a package manager

- simple-to-use build tools with dependency discovery

- mostly-optional garbage collector (great for 90% projects!)

- interfaces with C and C++

- memory safe

C++ still has:

- header files

- a preprocessor

- infamously hard-to-parse syntax

- decades of legacy cruft

- fun things like design-by-SFINAE

My biggest reason to use D is that it works great for both small scripts (one program can be one file and is ran with one command, or even a shebang), and large projects (with packages / dependencies etc.). Similarly, if idiomatic D is too slow, you can optimize it by going as low as C or inline assembler without having to call-out to a lower-level language.

Source: using D for almost everything since 2006, while also maintaining a few C++ projects.

The issue with D, I guess, how do you find gigs? :)

Looking past the feature comparisons, it's simply a pleasure to program in D. It's easy to write code in D, it looks good once written, it's easy to refactor, and it performs as well as the equivalent C or C++ code.

The features are designed with an eye towards simple things should be simple, code should not have to written twice, the layout of the code should match the layout of the problem being solved (not the language), drudgery should be eliminated, and common bugs should be impossible.

One thing that I like the look of in D (although just the LLVM version) is DCompute.

It's GPGPU functionality with an absolute minimum of boilerplate. Unfortunately it does not seem to be in active development.

I'm not dead yet.

I've just had a bit of fun updating the SPIR-V backend to use https://github.com/KhronosGroup/SPIRV-LLVM-Translator instead of the old one which wasn't being updated. I'm in the process of adding clspv as a backend for Vulkan Compute shaders (in turn as a basis for targeting Intel's ispc compiler optimisations). Most of that fun involves bashing CMake around that head to try to get it to talk properly with pkg-config (I hate them both).

Nice. Thanks for doing the ugly work so that other people don't have to.

D is still miles ahead of C++ if you care about compile times, even in pathological cases (like using tons of templates and/or CTFE in your D code).

When I hear about fast compile times, like e.g. for Pascal, immediately comes to mind - how good is optimization of the resulting executable? AFAIK, the back-end, not the front-end/parsing, takes most time when compiling C++. So in case of GCC or LLVM based D compilers, the time should be similar?

> AFAIK, the back-end, not the front-end/parsing, takes most time when compiling C++

Is there a reason why you believe that to be true?

> So in case of GCC or LLVM based D compilers, the time should be similar?

They are not: https://atilanevesoncode.wordpress.com/2018/12/31/comparing-...

C++ 11, 14 and 17 have all closed the gap with D in terms of features, but IMHO even when those features exist in C++ they're a lot harder to use and a lot easier to shoot oneself in one's foot.

You _can_ get things done in modern C++, it just takes longer and is buggier. In my experience, anyway.

try D! its a seemingly weird mixture of scripting languages and compiled ones. but ill all makes so much goddamn sense once you try it :)

Totally agree. It's been a while since I have last used D but my experience is that it hits a sweet spot between classical C-like compiled programming languages and scripting languages. If you need both, scripting and performance, D is a good pick. If you are already familiar with C or C++, getting into D is not that hard.

Disclaimer: Nowadays I am more enthusiastic about Rust than D, but I still consider D to be a very solid and nice language.