<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 8:02 PM, Garrett Smith <span dir="ltr"><<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Thu, Feb 13, 2014 at 12:15 PM, Joe Armstrong <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>> wrote:<br>
><br>
> On Thu, Feb 13, 2014 at 10:51 AM, Garrett Smith <<a href="mailto:g@rre.tt">g@rre.tt</a>> wrote:<br>
>><br>
>> Sigh. This *is* confusing. It just is.<br>
>><br>
>> Loïc you *cannot* use Erlang without OTP. The VM starts a system,<br>
>> which consists of applications, which are supervisory trees of<br>
>> gen_servers.<br>
><br>
> This is wrong - you can use Erlang without OTP.<br>
><br>
> OTP loads 60 odd modules, starts a code server and some other stuff and<br>
> *then* executes your code.<br>
><br>
> You can "easily" roll your own system that uses far fewer modules and gets<br>
> you up<br>
> and running, but then you don't get the shell, the code loader and a load of<br>
> other goodies.<br>
><br>
> Appendix 3 of the 2'nd edition of Programming Erlang tells you *exactly* how<br>
> to do this.<br>
><br>
> To summarise Appendix 3 - I load 3 modules in 20ms instead of the 1.1s<br>
> Erlang + OTP takes (on the same machine) then you're up and running, not OTP<br>
> but a with a code loader and simple I/O system.<br>
<br>
</div>Book ordered.<br>
<br>
The prospect of getting off the OTP facility is very appealing. If<br>
it's that trivial to get the same features without incurring the cost<br>
of those modules, I'm in.<br></blockquote><div><br></div><div>No - it is absolutely not trivial to get the same features as OTP. If you get the same</div><div>features as OTP then you'll have to reimplement OTP.</div>
<div><br></div><div>It is easy to get something that starts really quickly, loads code but which does *not* have all</div><div>the OTP goodies.</div><div><br></div><div>What *is* a problem is the blind adherence to OTP patterns when these are not appropriate.</div>
<div><br></div><div>The problem is not so much that people follow the OTP design principles, but that they</div><div>follow them in situations where it is inappropriate. Unfortunately it takes a while before you</div><div>
know which approach is best. You have to code up a solution to a problem with and without</div><div>the OTP libraries. For example write a server using gen_server and without gen_server and see</div><div>which is best. Note that most books start with how to write a server *without* gen_server.</div>
<div><br></div><div>Writing a statefull server *without* gen_server is really easy:</div><div><br></div><div>loop(State) -></div><div> receive</div><div> {From, F} -></div><div> {Reply, State1} = F(State),</div>
<div> From ! {self(), Reply},</div><div> loop(State1)</div><div> end.</div><div><br></div><div>With</div><div><br></div><div>rpc(Pid, Q) -></div><div> Pid ! {self(), Q},</div><div> receive</div>
<div> {Pid, Reply} -></div><div> Reply</div><div> end</div><div><br></div><div>The above code is basically all that gen_server does. gen_server just adds a few goodies to stop</div><div>you shooting yourself in the foot.</div>
<div><br></div><div>Now take pure libraries as an example - these are in pure Erlang, no registered process, no supervision. I've often seen these built together with the entire application infrastructure. </div><div>
<br></div><div>If it's a pure library there is absolutely no reason to do application:start(blaa) etc. and make an</div><div>application for this - unless (and this is a big unless) - unless you want to make a strictly compliant</div>
<div>OTP application and dynamically unload and reload the code at run time. In the vast majority of cases</div><div>this is totally unnecessary and letting the dynamic code loader do it's job will suffice.</div><div>
<br></div><div>In the very rare case that you actually do want to strictly manage your code in an environment</div><div>that is designed to *never* be stopped then you need the application structure - but this can be</div>
<div>added at the very end of the development processes.</div><div><br></div><div>Getting the process structure clear without regard to the OTP libraries is far more important.</div><div><br></div><div>I've also see cases where code really does not fit the OTP behaviours, the code is ugly and</div>
<div>unnatural - a clear sign that the underlying libraries should not be used.</div><div><br></div><div>The entire OTP infrastructure was designed for enterprise systems that should *never* go down.</div><div><br></div><div>
It was NOT designed for shell scripting, programs where taking the service down</div><div>for a quick reboot is not a problem.</div><div><br></div><div>We can reboot an erlang system rather quickly (under 2 seconds, I guess) - If you can live with this</div>
<div>then you can forget about release upgrades etc. Only very demanding systems need the release upgrade </div><div>stuff.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think the needle could move here.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>I think that something like e2 with less ceremony than OTP would be great.</div><div><br></div><div>There seems to be a gap:</div>
<div><br></div><div> OTP => targeted for enterprise grade 24x7 stuff</div><div> ?? => can take system out of service for a few seconds occasionally</div><div> escripts => quick and dirty shell scripts</div>
<div><br></div><div>The ??? is not well served. Something like e2 with a quick-start and packaging facility</div><div><br></div><div>Using OTP with all the release/application/supervisor stuff is building enterprise grade</div>
<div>software for non-enterprise grade applications - which really is using a battleship to crack a</div><div>walnut. Problem is we don't have a simple nutcracker.</div><div><br></div><div>Cheers</div><div><br></div><div>
/Joe</div><div> </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Garrett<br>
</font></span></blockquote></div><br></div></div>