Sircmpwn (the main developer behind the Sway Wayland compositor) recently wrote a blog post about how he thinks Rust is not a good C replacement. I don’t know if he’d like the D programming language either, but it’s become a C replacement for me.
My C to D Story
My story is like a lot of systems programmers’ stories. At one time, C was my go-to language for most programming. One day I realised that most of my C programs kept reimplementing things from C++: dynamic arrays, better strings, polymorphic classes, etc. So I tried using C++ instead, and at first I loved it. RAII and classes and generics made programming fun again. Even better was the promise that if I read all these books on C++, and learned to master things like template metaprogramming, I’d become an almighty god of systems programming and my code would be amazing. But learning more eventually had the opposite effect: (in hindsight) my code actually got worse, and I fell out of love. I remember reading Scott Meyer’s Effective C++ and realising it was really more about ineffective C++ — and that most of my C++ code until then was broken. Let’s face it: C might be fiddly to use, but it has a kind of elegance, and “elegant” is rarely a word you hear when C++ is involved.
Apparently, a lot of ex-C C++ programmers end up going back to C. In my case, I discovered D. It’s also not perfect,
but I use it because it feels to me a lot more like the
1 that C++ was meant to be. Here’s an example that’s very superficial, but I think is representative. Take this
simple C program:
Here’s a version using the C++ standard library:
Here’s an idiomatic D version:
As I said, it’s a superficial example, but I think it shows a general difference in philosophy between C++ and D.
(If I wanted to make the difference even clearer, I’d use an example that needed
iomanip in C++.)
Update: Unlike in C, D’s format strings can work with custom types. Stefan Rohe has also pointed out that D supports compile-time checking of format strings using its metaprogramming features — unlike C which does it through built-in compiler special casing that can’t be used with custom code.
This article about C++ member function pointers happens to also be a good explanation of the origins of D. It’s a good read if you’re a programming language nerd like me, but here’s my TL;DR for everyone else: C++ member function pointers are supposed to feel like a low-level feature (like normal function pointers are), but the complexity and diversity of implementations means they’re really high level. The complexity of the implementations is because of the subtleties of the rules about what you can do with them. The author explains the implementations from several C++ compilers, including what’s “easily [his] favorite implementation”: the elegantly simple Digital Mars C++ implementation. (“Why doesn’t everyone else do it this way?”) The DMC compiler was written by Walter Bright, who invented D.
D has classes and templates and other core features of C++, but designed by someone who has spent a heck of a lot of time thinking about the C++ spec and how things could be simpler. Walter once said that his experiences implementing C++ templates made him consider not including them in D at all, until he realised they didn’t need to be so complex.
Here’s a quick tour of D from the point of view of incrementally improving C.
D compilers support a
-betterC switch that disables
the D runtime and all high-level features that depend on it. The
example C code above can be translated directly into betterC:
The resulting binary looks a lot like the equivalent C binary. In fact, if you rewrote a C library in betterC, it could still link to code that had been compiled against the C version, and work without changes. Walter Bright wrote a good article walking through all the changes needed to convert a real C program to betterC.
You don’t actually need the
-betterC switch just to write
C-like code in D. It’s only needed in special cases where you simply can’t have the D runtime. But let me point out
some of my favourite D features that still work with
This allows verifying some assumption at compile time.
Systems code often makes assumptions about alignment or structure size or other things. With
static assert, it’s possible to not only document these assumptions, but
trigger a compilation error if someone breaks them by adding a struct member or something.
Typical C code is full of pointer/length pairs, and it’s a common bug for them to go out of sync. Slices are a simple and super-useful abstraction for a range of memory defined by a pointer and length. Instead of code like this:
You can use this much-less-bug-prone alternative:
A slice is nothing but a pointer/length pair with first-class syntactic support.
Compile Time Function Evaluation (CTFE)
Code in one part of a function is often coupled to cleanup code in a later part. Failing to match this code up correctly is another common source of bugs (especially when multiple control flow paths are involved). D’s scope guards make it simple to get this stuff right:
You can even have multiple scope guards in a scope, or have nested scopes. The cleanup routines will be called when needed, in the right order.
D also supports RAII using struct destructors.
It’s a popular myth that
const in C and C++ is useful for compiler optimisations. Walter
Bright has complained that every time he thought of a new
const-based optimisation for C++, he eventually discovered it didn’t work
in real code. So he made some changes to
const semantics for
D, and added
immutable. You can read more in the D
Functional purity can be enforced. I’ve written about some of the benefits of the
pure keyword before.
SafeD is a subset of D that forbids risky language features like pointer typecasts and inline assembly. Code marked
@safe is enforced by the compiler to not use these features,
so that risky code can be limited to the small percentage of the application that needs it. You can read more about SafeD in this article.
Like I hinted earlier, metaprogramming has got a bad reputation among some C++ programmers. But D has the advantage of making metaprogramming less interesting, so D programmers tend to just do it when it’s useful, and not as a fun puzzle.
D has great support for compile-time reflection. In most cases, compile-time reflection can solve the same problems as run-time reflection, but with compile-time guarantees. Compile-time reflection can also be used to implement run-time reflection where it’s truly needed.
Need the names of an enumerated type as an array?
Thanks to D’s metaprogramming, the standard library has many nice, type-safe tools, like this compile-time checked bit flag enum.
I’ve written more about using metaprogramming in
Okay, this a non-feature as a feature, but D has no equivalent to C’s preprocessor. All its sane use-cases are
replaced with native language features, like manifest
constants and templates. That includes proper
modules support, which means D can break free of the limitations
of that old
C-like D code can be written and compiled as normal D code without the
-betterC switch. The difference is that normal D code is linked to the D
runtime, which supports higher-level features, the most obvious ones being garbage collection and object-oriented
classes. Some people have confused the D runtime with something like the Java virtual machine, so I once wrote an article explaining exactly what it is (spoiler: it’s like the C and C++
runtimes, but with more features).
Even with the runtime, compiled D is not much different from compiled C++. Sometimes I like to write throwaway code to, say, experiment with a new Linux system call or something. I used to think the best language for that is plain old C, but now I always use D.
D doesn’t natively support
#includeing C code, but for
nice APIs that don’t have a lot of preprocessor craziness (like most of Linux) I usually just write ad-hoc bindings. Many popular C libraries have maintained D bindings, which
can be found in the Dub registry, or in the Derelict project, or in the newer BindBC
project. There are also tools for automated bindings, including the awesome dpp tool that brings
#include support directly to D code.
Update: This post has got a lot of attention from people who’ve never heard of D before. If you’re interested in learning D, I recommend