> 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.