# Some Reasons to Program D

This post is part of my Thirty Days of Things, an attempt to post one article on this blog every day for 30 days.

Would you look at that! Four days into the challenge and I already missed a day. Guess I have to post two things today to make up for it.

## the trouble with C

SDL is one of the most basic libraries for programming GUIs with windows, graphics, and user input. It’s often recommended as a library for game development with languages like C and C++.

Every now and then, I get an itch to do some low-level programming with SDL, but usually I get put off pretty quickly by using C. It’s hard to compile, you have to keep header files updated, there’s no module system for organizing code, and manual memory management is the only game in town. C++ offers debatable improvements on C, but still suffers from these same problems.

Of course, you can call C libraries from just about every language on the planet, so I could really pick any language for this. The problem is that the idioms of C and SDL often translate poorly to other languages. What I would really like is a “modern” version of C that:

• has a package manager
• is easy to compile on any system
• supports modules
• doesn’t require writing header files
• can be written like C without breaking language idioms

## guess the pattern: A, B, C…

In my opinion, D is the best language given those criteria. Like C++, it aims to be a “better C” with more modern features. In addition to those listed above, it also offers:

• garbage collection, but you can turn it off
• convenient handling of strings and arrays
• built-in unit testing

## source code example

This is what it looks like to read a file line-by-line in C:

// code slightly modified from https://stackoverflow.com/a/9206332
#include <stdio.h>

int main(int argc, char* argv[]) {
if (argc < 2) {
printf("missing required filename parameter\n");
return -1;
}

char const* const fileName = argv[1];
FILE* file = fopen(fileName, "r"); /* should check the result */
if (file == NULL) {
printf("failed to open file %s\n", fileName);
return -2;
}

char line[256];

while (fgets(line, sizeof(line), file)) {
/* note that fgets don't strip the terminating \n, checking its
presence would allow to handle lines longer that sizeof(line) */
printf("%s", line);
}
/* may check feof here to make a difference between eof and io failure -- network
timeout for instance */

fclose(file);

return 0;
}


This is the same function in D:

import std.stdio;

int main(string[] args) {
if (args.length < 2) {
writeln("missing required filename parameter");
return -1;
}

auto filename = args[1];
auto file = File(filename);

foreach (line; file.byLine()) {
writeln(line);
}

return 0;
}


The D code, aside from being much shorter thanks to the standard library, is also much more readable. Thanks to the garbage collector, there are fewer opportunities to make silly mistakes. And if garbage collection becomes a bottleneck, you can turn it off for particular functions by annotating them with @nogc.

This isn’t to say that D is “better” than C, but it’s definitely easier to write. That’s important for hobby projects where you need to accomplish things often to stay motivated.

## final thoughts

It goes without saying that D does not have nearly the same level of adoption as C or C++. There are fewer open-source libraries, fewer success stories, fewer corporate sponsors, etc. Additionally, it’s not obscure because it’s new– D has been around since 2001, but has already been eclipsed by Go, which appeared in 2007, and Rust, which appeared in 2010.

But for a hobby project, especially one that relies on popular C libraries like SDL, there’s no reason to let poor adoption get in the way of learning something new.