Ruby Arduino Development

Memory is the bigger issue, the most popular Arduino variant has 2K of RAM and under 32K of program memory. I wouldn't be surprised if the implementations of Ruby's library functions and data structures (array, hash, etc.) eat up most of it.

It's such a shame that the current embedded systems crowd keeps beating this dead horse. Performance is not the only metric by which to quantify the performance of a system.

Any engineer worth his salt knows that everything is a trade-off, and there are many, many projects where embedding an interpreter is a good choice. It can buy you things like design agility, memory safety (robustness, security), run-time linking (remote code updates), garbage collection (robustness), green threads (maintainability due to separation of concerns, memory-efficient if done correctly)

In terms of cost, an interpreting JVM will typically be 20x-100x slower than equivalent C code depending on the application (although technically C doesn't do automatic bounds checking and isn't type safe, so it's not really equivalent). Garbage collection often introduces pause times as embedded GC tends to be less complicated than server-grade, but you can still implement time-critical stuff in C. For example, the .NET/TinyCLR based Fez Panda board has no problems doing one-wire because of this. Finally, you tend to be less memory efficient because your high-level language might be OO, doesn't know about bytes/shorts/ints but rather just has the type 'Number', and because of GC.

If you blindly follow the 'performance is everything' mantra, you forget that there is a whole slew of applications where you really don't need 20MHz, and where things like robustness and security are way more important than real-time. The few extra K of memory for the micro might cost you a couple of extra cents, but it can save you a lot of development time. Depending on the volume this might be an appropriate choice.