Hey Paolo,
With a native-compiled proof of concept like Llilum, you still have real-world issues like garbage collectors to deal with. There is a possibility that a GC-less application could be built, and there is a possibility that a GC which honors determinism around interrupts is possible. But to be clear none of these are announced features--or necessarily on the roadmap. It's all very early still, and we're just super-excited for the new bits.
Chris
I think none would need (strictly-speaking) a Real-Time-Netduino, otherwise you'd opt for a different beast, and -yes- maybe programming in some native language.
Instead, I believe the typical req' of the Netduino user is the ability to interface with some I/O: that is, bit-banging, hi-res capture, etc.
So, all the Netduino would need is some hacky-ability to plug a native-coded section. Let's say the "Go" idea, but full-software solved.
I remember an user of this forum, who was very smart, and created kinda "hook" so that the regular C#-managed code ran together with machine-language bits of program.
I always thought that was the right direction although his own solution was actually too cumbersome to use.
Just think to an Arduino-sketch (better: template) against a bunch of Netduino APIs, and the result should be linked to the main app. Although a static linking would require way less resources, I'd rather look in the dynamic one: paying more, but the benefits are satisfying.
Maybe a tiny-tiny Windows COM interface or so...
My two cents...