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