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
