[erlang-questions] node.js compared to erlang

[Anthony Molinaro]

On Fri, Oct 08, 2010 at 12:18:32AM +0100, Dale Harvey wrote:
> I think its time to settle on and promote tools like rebar / mochiweb /
> learnyourselfsomeerlang / unknown package manager / and not wait for things
> to be officially blessed by the otp team, they are busy making erlang
> awesome, we as a community need to pick up the slack on that end.

Just wanted to mention framewerk (http://code.google.com/p/fwtemplates/)
and erlrc (http://code.google.com/p/erlrc/).  The former provides an
erlang template which allows you to quickly get a development package
up and running which includes the following

- generates a hello world style app when you initialize a new project
- provides the building of .erl files using make
- automatically builds .app and .appup files according to appup cookbook
- has eunit, dialyzer and cover integration
- builds debs, rpms or just tar.gz's.
- manages dependencies and maps those to the packaging system you are
  using
- integrates with your version control system to tag when you release a
  package

It also integrates which erlc which makes deb and rpm attempt to use
hot code loading when you install packages.

I use this currently by running an erlang node on a machine and having
everything I install packaged as an rpm.  If a new rpm is available
I can use yum/rpm install and it will attempt a hot code upgrade during
the installation.  It still has a few problems on RHEL but they are usually
a result of broken code_change handlers.

It's a great model, because you can have multiple applications versioned
separately all running in the same node.  If you need to launch to multiple
nodes it ends up being as easy running for h in host1 ... host2 ; do ssh
$h "yum install new_package" ; done.

I've ended up repackaging many open source erlang projects as framewerk
projects just so I can get erlrc and rpm integration.

I've not played with rebar, but it seems to want to make a single application
which is fine for a download and test sort of setup, but when deploying
different applications to 100s of production machines, using standard
packaging managers works really well.

Anyway, I like it, and I think it brings something to the table in that
it sort of skips the "lets build a package management system different from
all other package management systems", and instead tries to work with the
most common systems (rpm and deb).  It's also possible to add other package
management systems, so you could for instance get it working with faxien as
an alternative packaging system, making it possible to release packages in
many forms easily.

-Anthony

-- 
------------------------------------------------------------------------
Anthony Molinaro                           <anthonym@REDACTED>