Jérôme M. Berger wrote:
Embedded x86 is an oxymoron. Yes, I know, it exists (and btw, 8
years ago they were still selling 486s as "embedded" processors) but
mostly it doesn't need any special support (except possibly on the
binary size front and even there 80k is nothing to the XXX megabytes
used by the off-the-shelf OS+GUI+Web browser). Face it, there are
two kinds of embedded developers:
- Those who want performance at very low power usage, who use ARM
and C with a specialized OS. Those won't use D, period. Most of the
time, they won't even use malloc or most of the C standard library
(not saying they're right here, but I doubt you will change them);
I've looked at some embedded ARM evaluation boards that have Linux on
them. Don't know much else about them. What about things like phones,
game machines?
- Those who only care about cost, who use x86 with Windows or Linux,
off-the-shelf software and an AJAX GUI and wonder why their systems
are so slow and won't even run a full day before needing to be
plugged to a power outlet. Those won't use D because "nobody uses
it" and anyway it takes too much space (don't ask me to explain the
logic behind that statement, I don't understand it either).
More seriously, I don't expect D to see much usage in the embedded
market unless it becomes a huge success on the PC first (if then).
But nothing you can do on the technical front will change that: it's
mostly due to prejudice and preconceptions, not an actual
cost-benefit evaluation of the language.
Yeah, I know, I run into the pseudo-problem all the time of D using
garbage collection. I point out that you can call/use malloc in D as
easily as you can in C++, but it makes no difference. They're convinced
that gc will send their app to hell. <g>
I fault Java, C#, Python, etc., for some of this anti-gc silliness
because those languages make it really hard to use malloc. They just
don't believe that malloc is trivial to use in D.
I get this perspective even from career experts in programming.
PS: At work, we mustn't use C++ because:
- It's slow;
- Its standard library is too big (100k);
- In a future product, we might want to reuse this module and not
have C++ (Oh, yes I didn't tell you that we *do* have the C++ stdlib
in our products because the web browser they bought to run their
HTML+Javascript+HTML+XML+C+XML+C+XML+C GUI uses it, but *we* aren't
allowed to, fckng morons)
!!
