[erlang-questions] Stand Alone Erlang or Equivalent

[Kenneth Lundin]

Hi,

On 9/4/07, Benjamin Tolputt <bjt@REDACTED> wrote:
> I was wondering if anyone has actually made progress/headway into the
> "stand alone erlang" problem/feature?
>
> I am currently using Erlang for a variety of minor, yet high-concurrency
> tasks on our servers. I am currently looking into moving some of our
> more complex/CPU-intensive tasks to Erlang as well. And for these tasks,
> Erlang/CEAN/OTP distribution method is just fine (not my preferred, but
> that is only a matter of taste).
>
> However, I have been talking to a few busy individuals who (inspired by
> Tim Sweeney's latest talk) are looking at high-concurrency
> languages/executable frameworks for "client-side" game/simulation
> execution. They asked me which one I would recommend, and I (of course)
> mentioned Erlang. To which their immediate reply was "Yeah, it looks
> good - but the deployment is to much of a hassle for general game players".

I think you and many others discussing Standalone Erlang are mixing up
things here. The important thing for end user deployment is that it is
easy and quick
to install and uninstall a SW package and that does not imply that for
example all the beam files must be packed together in one or a few
bigger files.
As long as the installation is distributed as e.g a self extracting
and self installing exe file  (Windows) it should be ok.
Of course this package should only contain the beam files from OTP
that are actually used plus the specific .beam files for the SW in
question.

>
> So I was wondering if I could impress them with some news on the Stand
> Alone Erlang front. In a related question, how easy is it to retrieve
> code/beams from non-file based sources (e.g. from an embedded native
> code database or zip file)?
We have already implemented (but not released) code loading from ZIP archives.

We are working on "standalone" features but I can not promise today when we
will release something.


Erlang/OTP as available today as open source is a DEVELOPMENT SYSTEM
which the developer uses to create a TARGET SYSTEM. The target system
can be a simple standalone application to be installed on many clients
or it can be
a complex distributed embedded server system.

To create the target system you need the following:
1) Know what parts of Erlang/OTP you need in the target app.
You can pick OTP components on complete application level i.e. stdlib,
kernel, mnesia etc. which is easy. Or you can try to remove unused
modules even from stdlib, kernel etc. which is more tricky and
requires a lot more knowledge about dependencies.
2) Know your own target specific SW.
Must be obvious.
3) Pack 1 and 2 together in a distribution.
You can pack together all resulting files and directory hierarchies
just as they are.
Or you can try to create something which result in just a few files
when installed (e.g. beam files packed together, one per OTP
application or one for all .beam files)
4) Installation script or other SW run at install time
You can for example use NSIS (free and we use it now) for Windows or
something else.
For other OS:es you need something else.

We will primarily address 1 and 3 above and probably offer several
alternatives for
doing them.
We will not take the SAE approach exactly as the one Joe Armstrong did because
we have found several difficulties in maintaining that solution.

/Kenneth (Erlang/OTP team at Ericsson)



>
> Thanks for any feedback you might have on this...
> B.J.Tolputt
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>