D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

[Claude via Digitalmars-d]

> Bottom line is, if you are competent enough, you can be 
> successfull with D, just like you would be if you were using 
> C/C++. D's superior compile-time meta programming allows you to 
> express zero cost abstractions give you the edge that makes 
> things more enjoyable.
>
> There are several open-source kernels written in D that are 
> proof of the above:
> https://github.com/Vild/PowerNex
> https://github.com/Bloodmanovski/Trinix
> https://github.com/xomboverlord/xomb
> Adam Ruppe has a chapter about bare-metal programming with D in 
> his Cookbook.

I do think D may be a perfectly valid real-time language. And 
indeed, I believe that the GC is not an issue (you can disable 
it, question solved).

However, is D a proper Embedded System language? I'm not pretty 
sure it's there yet.
Plain C rules the world of embedded systems. All the RTES 
programmers I've met are reluctant to even use C++.

If you cannot program a 16-bit PIC in D, then D will not replace 
C at all (but is it meant to?).

The open-source kernels above are targeted at PC architecture.
I know some work have been done to make bare-metal OS targeted at 
ARM. I don't know what's the state of those projects, and I'd 
love to make my own once I have time (based on Rasberry Pi for 
instance).

To validate D as a proper Real-Time Embedded System, one would 
have to make a proper bare-metal OS a ARMv5 chip (for example). 
Write your Interrupt Service Routines in assembly calling D 
functions, program the MMU, the different hardware blocks (UART, 
INTC, USB etc).
And the API of such an OS would benefit of the expressiveness 
power of D (templates, traits UDA etc) and not just be a C-style 
clone, with an efficiency similar to C (at least same CPU load).