Five years ago, I was trying to learn the D programming language. After completing a project and a half to disappointing results, my attention turned to Nim instead. That worked rather better up to a point, but some issues caused me to move on again. And as things always go full-circle, I'm now trying to get back into D.
Call me indecisive if you like, but that gives me a unique opportunity: to compare the two languages directly, while porting a toy project between them. Having more experience now is a bonus.
First impressions: there are three different implementations of D (though they share a common front-end). It's a pretty big package no matter which one you pick, if lighter than for other languages, and stand-alone. More on this later. Conversely, there's just one Nim compiler. It's much smaller, but requires a separate C toolchain as back-end. On the plus side, Nim is more widely available and easy to set up for cross-compilation.
Flavor-wise, D is a curly-brace language, while Nim has Python-like syntax (with influences from Pascal). Nim is noisy however, with lots of punctuation. Both are huge, complex languages that take a long time to learn, let alone master. On a more positive note, both support Uniform Function Call Syntax – a rare treat – as well as runnable examples that get included in generated documentation, but are first checked by the compiler.
On top of that, D supports placing unit tests right in your source, and can produce code coverage reports. Beware of overdoing it however! There are debug blocks too, which can be useful because D lets you crash programs via null pointer more easily – however it will print a stack trace when it happens. Nim claims to protect you from that, but its type system is easy enough to trick.
- Both languages have optional garbage collectors, enabled by default.
- Both compilers boast good build times. No, they aren't. Average at best.
- Both projects favor liberal licenses: Boost and MIT, respectively.
In the way of object-oriented programming, D has all the usual goodies: classes, interfaces, mixins, you name it. Nim has object types, which should be more flexible, but in practice it's hard to even see which operations apply to a type at a glance. It has algebraic types too; that's cool, but takes as much work as D's Variant if not more. The way you construct objects in Nim is a kludge, but at least you can choose the allocation model per type. In D classes are reference types and structs are values, period.
D makes everything public by default. Nim requires explicit exports.
One neat trick in Nim is that you can say, "this function takes any number of arguments and each of them is converted to a string on the way in". D's equivalent is more clunky, but you get cool magic like string mixins instead. Nim has templates and macros, but only trivial uses worked for me.
Performance
Last but not least, Nim emits small, fast executables. D makes them large, on par with other modern languages; both the runtime and standard library contribute to that. Performance is nothing to write home about either.
Contrary to point two above, compilers for both languages are in fact very fast, but the respective standard libraries are so heavy as to negate any advantage and make them feel sluggish. Nim at least lets you know what it's doing at every step, and I think its libraries are more granular. Plus, it caches temporary object files, saving time in the long run.
Conclusions
Which language to choose? Aside from technical aspects (or annoyances like Nim mandating spaces for indentation) there's the governance issue. D has a foundation behind it and a proper language specification. Nim has its creator and his informal team of contributors. I don't see much discussion as to how the language should grow. Yet Nim has been growing nicely, while D's creator has been criticized for holding it back. Sure enough, Nim gets the job done. D hasn't helped me so far.
Indeed, D seems ill-suited for small demos or hobby projects. This is a serious language for serious work. Nim can actually pass for a scripting language in a pinch. Not that I need yet another one of those. But someone else might.