Advocacy (Was: Who here actually uses D?)

[Ulrik Mikaelsson]

> So why is D being advertised as a systems programming language?  By saying
> Linus would not find D appealing you are basically saying kernel developers
> would not find it appealing.
"Systems programming" in my vocabulary is not limited to JUST kernel
programming. To be honest, I think D has a pretty long way to go to be
good for kernel development (irregardless of Linus/Linux). For kernel
development I suspect stop-the-world GC, or any non-deterministic GC
for that matter is a big no-no. Also, imagine the current frustration
over compiler/stdlib-bugs if you're operating in kernel-space, with no
GDB to help you track it down. That's not to say I don't think D COULD
be used for kernel development, but at the current state of things, I
don't think it's really a promising cost/benefit.

But systems development in my world doesn't end with the kernel,
system-development is everything up to the applications the users
really want, all libraries, codecs, file-format implementations etc.
I.E. i would be really interested to see what kind of systems-API
could be developed directly against the kernel ABI of *BSD or Linux,
if you ignore the libc-layer. I.E. what would a completely
event-driven (twisted) close-to-os stdlib look like, and how would
that improve the simplicity of writing performant I/O-driven
applications?

Currently, however, I think the D community (which I'm increasingly
being pulled into by common interests) should really focus on
low-hanging fruit, and proving to the larger developer-community why D
is worthwhile. In this area, I think the timing of D is perfect, given
the current trend of cheaper hardware, rather than more powerful
hardware.

For instance are there currently any good database-implementations in
D, suitable for beating the Tracker/Beagle/Strigi Desktop-search mess
of the open source desktops? Integrating such database with the
upcoming Linux fanotify API and libextractor should be an achievable
goal, and could perhaps even be a compatible drop-in replacement for
I.E. Tracker, but with lower footprint? I also have a stripped binding
for FUSE as part of BitHorde, so implementing a fuse-based
metadata-browser should be doable for integrating metadata directly
into the Linux VFS. Definitely good for showing off.