Erlang Micro Edition.

[Alex Arnon]

Okay, maybe Not-So-Micro Edition, if ME == mote-sized :)
I'm not talking about Erlang-in-64K, but rather devices with X MB,
where 4<X<32. I'm speaking of projects which should be rebuilt or
extened using Erlang, which cannot fit a >3MB VM (before code loading,
after linkage with local libs). I claim (humbly, of course :) ) that
project managers and team leaders for many products will never even
_try_ Erlang due to either practical concerns (space, portability) or
percieved risk. Give them "we can handle the overhead" and "hey, I
just embedded this after changing just two #includes" (a-la Lua).


On 6/29/05, Domonkos Asztalos (IJ/ETH) <domonkos.asztalos@REDACTED> wrote:
> Hi,
> let's move on.
> Do you think would it be realistic to try on a mote size node, used in sensor networks?
> /Domonkos
> 
> Domonkos Asztalos
> Ericsson Hungary
> 
> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]
> Sent: Wednesday, June 29, 2005 12:00 PM
> To: erlang-questions@REDACTED
> Subject: Erlang Micro Edition.
> 
> 
> Hi All.
> 
> I would like to hear your opinions on the usefulness of creating a
> small-footprint Erlang VM. Specifically, such a project might follow
> the J2ME approach, where the VM+basic libraries are cut down versions
> of the full environment, while retaining compatibility to code
> compiled using the standard tools. This would mean that while BEAM
> files should be loadable and linkable in runtime by the VM, fewer BIFs
> and a much smaller set of standard libraries would be supported
> relative to the standard ERL, and possibly less functionality out of
> the door (e.g. no distribution initially). Such a VM might also add
> some functionality, e.g. features for stricter resource management
> (this is meant for relatively small embedded systems).
> The basic aims of such a project:
> - To bring Erlang to the table of embedded software engineers (and as
> a generally embedded lightweight language/environment). The current
> standard Erlang implementation is neither lightweight nor portable
> enough for many projects.
> - The idea is to "give them a taste" of the full Erlang - while some
> enterprising devs would try something like Lua today (easy integration
> with C/C++, low resource consumption, level of abstraction, dynamic),
> Erlang should be a more attractive option for many problem domains.
> - To reduce the risk of same embedded/other devs. As I said above, Lua
> is often chosen because it is a small, lightweight environment, and it
> is easy for developers and project managers to try it out on a small
> scale before committing large parts of the project's high-level logic
> to it. In the case of systems which do not require a small-footprint
> VM, this will also give the developers a migration path to full-blown
> Erlang (which is where we want them, really :) ).
> 
> Do you find this to be sound reasoning, or is the whole idea
> superfluous in your opinion?
> 
> 
> Cheers,
> Alex Arnon.
>