Why we chose not to use D for our Linux project

[Chris Wright]

Bill Lear wrote:
> Sadly, we have given up on using D for our Linux project, despite my hopes and favorable overall impression of the D language.  I thought I would share briefly our reasons in hopes that the information is useful to those in the D community.
> 
> We are writing a distributed media publishing system that uses a relational database to store media programming schedules and other related information.  We need a language that has a library that provides easy database access (something along the lines of Perl's DBI, for example), CGI programming support, access to system-level routines, reasonable performance, YAML support, and other features.
> 
> We came to a quick conclusion that D wasn't going to work, as the DBI code proffered on dsource has apparently been abandoned and does not come close to compiling with the current dmd (1.028 or 1.029) compiler.  We had a laborious run-around trying to figure out if DBI requires Tango or Phobos, wrestled with the "bud" make-ish system, and finally gave up in disgust --- it just wasn't going to work without serious effort.

The last stable release of ddbi compiles on the most recent releases of 
dmd and tango with about twenty minutes' work. However, when compared 
with the Active Record implementations in Ruby, Python, and C#, and the 
various Hibernate-like libraries, D has nothing comparable.

There's an issue of having no convenient way of supplying metadata on 
UDT members. The best method I've come up with is:

1. Define a template that takes the metadata arguments.
2. This template expands into a string containing a static constructor.
3. The static constructor adds some data to a metadata aggregator 
singleton, keyed to the ClassInfo of the current class.
4. By the way, you can't initialize that singleton with a static 
constructor, because that might be called after the static constructor 
that creates the instance.
5. Now, instead of querying the typeinfo for the metadata, you query the 
metadata aggregator.

Ugly! And it turns the code from:

@Field(dbname = "id", primaryKey = true)
int id;

to:
mixin(Field!("id", true));
int id;

Or if you want named parameters, you use some string parsing scheme, 
like I did (actual code from a project I'm working on):
mixin(dbfield!("id", "name = id; primaryKey"));
int id;

> I think some serious attention needs to be focused on this, rather than the minutiae of the latest cool language feature.  I have been following D for some years now, hoping it would all come together --- and I hope it does, soon --- as it feels D is being left in the dust.

There are people working on it. Just relatively few, compared to the 
number of people working on Ruby or Python, both of which have been 
around a fair bit longer. There's an advantage that D is coming out 
later and thus doesn't have to do as much research in how to make decent 
libraries. But C# had some of that, and Ruby launched itself out of 
obscurity with that, so it isn't much of a competitive advantage.