General questions about the power of Erlang

[Maurice Castro]

> Hello,
> 
> 
> I am hesitating on using Erlang (for designing and implementing
> multimedia client server Internet applications).
> Would somebody please answer (some of) the following questions for me:
> 
> 
> 1)  If I look at the evolution from Java to Java for real-time (RT), the
> programmer will be able to specifiy physical memory desires in the Java
> for RT API.   The reason for this is because the Java for RT API will
> permit the programmer to use "Java physical memory objects".  This is a
> new class added to the Java RT API.
> 
> I am wandering whether I am able to do physical memory management in
> Erlang too?
> If I'm not mistaken, the semantics of Erlang were not designed for this
> purpose as opposed to concurrency and distribution which is well
> supported indeed.
> 
> If I am not able to specify physical (or even virtual) memory management
> constraints in Erlang, I still assume that I can change some
> functionality behind the scenes to obtain the same effect.
> 
> Does anybody have any experience on this subject?  Please enlighten me.
> The reason for this question is because I plan to implement multimedia
> applications.  These applications contain lots of dynamic data
> structures which I want to handle optimally with dynamic memory
> management.
> 

In Erlang you can make applications run in either fixed or bounded
space.  Using a generalised form of tail recursion called last call
optimisation you can ensure that your programs do not generate
continually growing stacks.  Naturally lists can grow in size depending
on their contents, but the programmer has the option of testing the
`size' of such a data item and deciding how to handle growth in such a
case. In general what are regarded as good programming practices in
Erlang will give you a stable space bounded program.

Furthermore, at least up until the recent past, Erlang's garbage collection
has been vastly better than that found in Java.

> 
> 3)  I read in the FAQ that application types, such as image processing
> and signal processing, are not meant to be implemented in Erlang.  (They
> would perform badly if they were implemented in Erlang.)
> I am wandering if research is being done on defining a new "Erlang
> approach" for these types of applications.  So instead of concurrent,
> distributed and hot code loadable applications, a new kind of Erlang
> semantics could be developed for data dominated, real-time, multimedia
> processing applications.
> 

Actually Erlang has a well defined approach to these application types:
Write then in a suitable language and call them from Erlang. Erlang has 
supported external programs for a long time and the advent of linked in
drivers has made access to programs in other languages even faster.

	Maurice Castro