d bare bones

[Ramon]

eles

Risking to find myself in hot water ...

I think that gc is grossly overestimated and it's too often 
painted in promised land colours. For one, there are, of course, 
trade offs; sometimes gc's advantages outweigh the disadvantages, 
sometimes not and close to hardware basically hardly ever.
Second, the problems to be solved by gc are equally 
overestimated, too. Looking back at many, many years of using C, 
memory management was basically never among the top trouble 
sources.

I don't know your situation in any detail but when doing work 
with MCUs (as in 8051, 68K, coldfire, mpc430, not as in Arm 
Cortex) I wouldn't even consider D.

D provides for interfacing C to quite some extent and I see that 
as extremely desirable and very much related (looking 
pragmatically) to D being C-like (unlike, say, Ada, which also 
provides quite nicely for interfacing C). I find that attractive 
for a simple reason; I don't need to switch my mindset and habits 
too much and can comfortably afford to follow the old and wise 
saying "Use the right tool for any job". Kernel, drivers etc -> 
C, userland system stuff, low level app stuff -> D, higher level 
stuff -> D with objects.
Yowsa, that's what I looked for.

If I were to criticize D then mainly for 2 points:
- It's following C's mindset too much on one hand and too little 
on the other hand. It seems visible to me that WB was driven by 
an itch and not so much by a vision (this is meant neither 
negatively nor positively; it's simply my impression and "driven 
by vision" doesn't necessarily lead to better results).
- It's not as consistent as I'd like it to be. phobos seems, uhm, 
worthy a discussion e.g. concerning at least its design (e.g. 
layers, OS interface), safety has been a concern but might have 
profitted by learning more from other languages, etc. Similarly 
there are bits all over the place but very little consistently 
implemented. That's another example why I value Iains work so 
emminently; he has brought us a complete and (at least 
principally) portable toolchain incl. debugging which is a 
conditio sine qua non.
As one example that relates to your situation, it might have been 
wiser to say "Our lower boundary is close to hardware or OS core 
stuff; we don't do that, that's were we cut off. But we provide a 
well designed interface to the tools of the plumbing trade, 
namely C and stdlib" rather than playing with the idea of (low 
level) system programming and not implementing it consistently.

But for fairness sake: Little (besides phobos, which *can* be 
improved) is in the way of doing it right, i.e. plumbing in C and 
anything higher up in D.

In case kernel and close to the metal jobs isn't the major part 
of your job it might be attractive to look at the C/D combo.

A+ -R