<div>Going to reply inline: <br></div><div><br></div><div class="gmail_quote">On Mon, Oct 17, 2011 at 8:17 PM, Gerry Weaver <span dir="ltr"><<a href="mailto:gerryw@compvia.com">gerryw@compvia.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br> Another issue that I've started to think about is deployment. There seem to be several competing tools/utilities for this. Is there a preferred or recommended solution?</blockquote>

<div><br></div><div>You've got 3 levels:</div><div><br></div><div>1. Rolling out basic Erlang. This is often done by people who do not want or know how to deal with the OTP framework, up to supervisors and applications. You'll see basic scripts calling main, scaffoldings of escripts and whatnot. This isn't something I'd recommend (not that Escript is the problem, but OTP is a nice way to work with code with the rest of Erlang programmers).</div>

<div><br></div><div>2. OTP Applications are being used. People up to there use OTP applications, can see dependencies and whatnot, and will manually start everything using calls to 'application:start(AppName)' in sequence. Again, escripts might be used here as a way to bootstrap the application. This model is somewhat sane, everyone can understand it, but might have problems when it comes to upgrading running code.</div>

<div><br></div><div>3. OTP Releases. They're a bit annoying to figure out. You've got two ways to package releases: reltools and systools. People will pick one depending on whatever they find most convenient. In any case, most people will tend to use tools like rebar to handle them (especially since rebar also handles downloading dependencies and whatnot). Despite the complexity, releases will have nice aspects, like automatically handling application dependencies, starting things for you, safely doing application and release upgrades (relups). If you're doing it by hand (or using cross-compatible tools), release building should be cross-compatible with other platforms.</div>

<div> </div><div>This doesn't mention how to do things like setting up distributed applications (more work with OTP apps/releases, central connection nodes, etc.), how people push code on servers (some people use Erlang to send code to other nodes with the code server and rpc, rsync it, use pulls with source control, Chef, linux packages, etc.) and a few other things.</div>

<div><br></div><div>Self-advertisement:</div><div>OTP Releases: <a href="http://learnyousomeerlang.com/release-is-the-word">http://learnyousomeerlang.com/release-is-the-word</a></div><div>Relups: <a href="http://learnyousomeerlang.com/relups">http://learnyousomeerlang.com/relups</a></div>

<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Is the Erlang language itself still evolving? The reason I ask is that the fellow that did CouchDB posted a blog entry about the things he encountered while developing CouchDB. What was interesting to me is how, even after a short time with the language, many of the issues he mentioned immediately rang true with me. For example, what is the benefit of the "; , ." terminators as opposed to a single terminator approach?<br>

</blockquote><div><br></div><div>Prolog would be the easy answer. </div><div><br></div><div>I would however want to correct you. The full stop is a terminator of Erlang <em>forms</em> and others (;,) are <em>separators for expressions and forms.</em> I won't get into too many details. I've decided to write a blog post on this a year ago because this is such a common complaint: <a href="http://ferd.ca/on-erlang-s-syntax.html">http://ferd.ca/on-erlang-s-syntax.html</a></div>

<div> </div></div>