[posborne]

Yes, I believe so. The binaries I have built so far have been very small (<2KB for a blink example). mcoffin has a branch with SAM3x support, which appears to be the processor on the Due: https://github.com/mcoffin/zinc/tree/sam3x

The Due has 512KB of room for code which is quite a lot (for microcontrollers).

[TickleSteve]

2KB to blink LEDS? seriously? this needs to be on the order of a few ten of bytes to be competitive...

[posborne]

A few points:

* I don't think a few tens of bytes is realistic for a real application that needs to set up the stack, timers, and then blink some LEDs (https://github.com/mcoffin/zinc/blob/new-build/examples/app_... / https://github.com/mcoffin/zinc/blob/new-build/examples/app_...)

* Assuming the code size overhead does not continue to bloat after some initial overhead, I think rust can still be very competitive. Although modern embedded systems are still very constrained, the days of 8-bit micros are basically over. You can buy a 32-bit ARM micro for nearly the same cost with sufficient RAM/Flash to run rust well.

* Looking back, I think the size of blink should actually be closer to 600 bytes. Will need to investigate: http://zinc.rs/stats/

[rkangel]

That depends on what's in there. My understanding is that that 2Kb is not so much overhead as required dependencies. Dependencies that most real applications would probably end up pulling in anyway, like a dynamic memory allocator.

The end of the market with tiny micros and extremely simple applications (like just blinking LEDs) is likely to never be well suited to Rust, but doesn't gain much from it anyway.

[Ygg2]

It probably can be lowered by manually linking and similar stuff.

See: http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-...