> My reading is that most of the problems come from a lack of manpower or perhaps a lack of delegation but I'm only reading this as an outsider. Preface: I don

> My reading is that most of the problems come from a lack of manpower or perhaps a lack of delegation but I'm only reading this as an outsider. Preface: I don't use D, but I've lurked on the forums for a while now since I've started looking for a low-level programming language. I would agree that this (manpower and delegation) is the main issue D is facing, and many others flow from it. Walter and Andrei are spread way too thin, while still being the main conduits and gatekeepers for all things D. For example, sometimes their responses can seem curt or dismissive, but I've come to the conclusion that they're just busy people, and for many back-and-forth communications short responses are fine if not better. My personal opinion is that what D really needs is more bureaucracy. Pre-defined processes where even casual contributors and other interested parties can follow along. I believe the "study" subforum was a good start, but is a bit too ad-hoc (and underused). The issue discussed in the original (stdlib coupling, integration of D built libraries into other systems) would be perfect for a study group. Start out with a Goals/Requirements document, come out with strategies, hindrances. Even when no solution is found or no consensus is reached, the archived discussion would be valuable in itself, for example as basis for a "Reasoning and Alternatives" document for the specific issue or mentioned use-cases. A more complex situation would be the optional GC. It is very much wanted, and lots of work is going into that (all the RC integration/experimentation, the scope annotation system, to just name the ones visible to a lurker like me). But I couldn't tell you the full plan, I'm unsure where D wants to end up (from a current standpoint) with regard to being usable without GC. From my point of view, there are still issues to be sorted out with closures, exceptions, arrays and slices, plus I'm unsure about how GC, RC and manual memory management are supposed to interact in the end. Now, from examples on the forums I can tell that using D without GC is doable and useful, so I would assume once you start doing it you find a way. But this is all harder to see from the outside. Which brings me to another point: Publicity. D could do with a lot more blog posts showcasing its more unique parts like great use-cases for the compile-time power D has: The memory management strategies, how to effectively use the safety system, how to do D concurrency and parellelism "right". I apologize this got a bit longer, I guess I waited for a cue to give some feedback on D, since I never felt like it was my place as a biased outsider to weigh in on their forums. In effect, I believe manpower is one of the biggest issues to get where they want to go. What I find interesting is that in my view it is non-development manpower that they actually need. Or rather, more efficient ways to attract it, or maybe even just more efficient ways to include the ones already there.