To D or Not to D

This week I decided to try out the programming language, D. For those unaware, D is basically an updated version of C++. It fixes some of the problems that C++ has and introduces a bunch of modern concepts. The biggest drawback of D seems mostly to be that everyone's already using C++. In any case, I decided to get my feet wet so I'll talk about my first impressions here.

The Good

D fixes a lot of small problems with C++ in better ways than C++11 did. It incorporates a few modern niceties like properties and foreach loops. D also uses a garbage collector, like C# and Java, and borrows their conceptions of reference types vs value types. Additionally, it's easy to bypass the garbage collector if you really want to manage memory manually. You can even combine the two methods if you really want.

Templates are, for the most part, much better in D. D templates are their own thing; no more dealing with the differences between function templates and class templates. Additionally, you can template other things, like constants and typedefs (known as aliases in D). They ditched the annoying Foo<Bar> syntax for Foo!(Bar). That might seem weird at first, but you get used to it quickly, and the parentheses can be dropped if you only have one parameter. Variadic templates are supported out of the box, and they're easy to work with. Any basic type can be a template parameter, including floats and strings (but oddly not arrays).

D has something called a static if, which allows you do conditionally compile things (including declarations). This is really useful for handling edge cases in templates. 

Mixins allow you to construct strings at compile time and then compile those strings into code. This is an incredibly powerful feature, but can also require a lot of work and has the potential to go horribly wrong. Additionally, they're really hard to debug.

Arrays are a lot different in D, but they're much closer to being first class objects. You can perform limited operations on arrays, eliminating a lot of tedious for loops. Concatenation is a separate operation, so it's never confused with addition. 

Modules allow for several things to be encapsulated in a namespace-like collection. Functions, classes, and variables can be made private to a module, which makes encapsulation less of a problem in its own right. Order of declarations is irrelevant within a module, which means no more forward declarations and no more recompiling header files over and over.

D can link with C and C++, so existing libraries can be used with a little work.

The Bad

D suffers some of the same flaws as C++. The pragmatic approach taken by the language designers has led to some awkwardly specific syntax and broken edge cases.

It infuriates me that it's still so hard to create a template function that takes exactly n parameters of type T. Strictly speaking, this is something you can do in D, but only if you use template recursion to create mixins. There are no anonymous templates in D. You can use a shorthand syntax for classes and functions, but are required to use the full syntax for constants and aliases. This usually ends up being pretty verbose, especially since you have to use the same name for both the template and the constant/alias (unless you want to do even more typing).

While D has static ifs, it doesn't have static loops. The justification for this being that unrolled loops aren't always faster. However, it also impedes one's ability to build generic classes. Where you might use static if for a few optional members, you have to use template recursion and mixins to create n optional members.

Where C++ compilers generally drown you in compile errors, D seems to leave you high and dry. Most of the errors I got while messing around seemed to be of the variety, "Something is wrong with this". They weren't vague, per se, but were usually far removed from the actual problem. I didn't have much luck finding solutions online either.

While the language is well documented, it's hard to find help with some of the nuances. However, this is probably because the language is still young and developing. Regardless, it took me a while to get started because I was unsure of a lot of details.

Conclusion

On the whole, I'm optimistic about D. Like C++, it has it's problems, but overall I consider it an improvement. It'll take some time before the language is widespread enough to compete with C++, but I think it's possible. I can think of only two reasons for a C++ programmer not to convert. First is legacy: there's a lot of old C++ code out there that's still being used. If you have to rely on that code, it's probably best just to stick with C++. Second is learning curve: D is a lot like C++ superficially, but it is a new language, and there's a lot to learn. It'll be a bit of a commitment if you want to switch over. In the end though, you might spend a lot less time pulling your hair out than you do with C++.