[erlang-questions] Time for OTP to be Renamed?

[Joe Armstrong]

On Thu, Feb 13, 2014 at 8:02 PM, Garrett Smith <g@REDACTED> wrote:

> On Thu, Feb 13, 2014 at 12:15 PM, Joe Armstrong <erlang@REDACTED> wrote:
> >
> > On Thu, Feb 13, 2014 at 10:51 AM, Garrett Smith <g@REDACTED> wrote:
> >>
> >> Sigh. This *is* confusing. It just is.
> >>
> >> Loïc you *cannot* use Erlang without OTP. The VM starts a system,
> >> which consists of applications, which are supervisory trees of
> >> gen_servers.
> >
> > This is wrong -  you can use Erlang without OTP.
> >
> > OTP loads 60 odd modules, starts a code server and some other stuff and
> > *then* executes your code.
> >
> > You can "easily" roll your own system that uses far fewer modules and
> gets
> > you up
> > and running, but then you don't get the shell, the code loader and a
> load of
> > other goodies.
> >
> > Appendix 3 of the 2'nd edition of Programming Erlang tells you *exactly*
> how
> > to do this.
> >
> > To summarise  Appendix 3 - I load 3 modules in 20ms instead of the 1.1s
> > Erlang + OTP takes (on the same machine) then you're up and running, not
> OTP
> > but a with a code loader and simple I/O system.
>
> Book ordered.
>
> The prospect of getting off the OTP facility is very appealing. If
> it's that trivial to get the same features without incurring the cost
> of those modules, I'm in.
>

No - it is absolutely not trivial to get the same features as OTP. If you
get the same
features as OTP then you'll have to reimplement OTP.

It is easy to get something that starts really quickly, loads code but
which does *not* have all
the OTP goodies.

What *is* a problem is the blind adherence to OTP patterns when these are
not appropriate.

The problem is not so much that people follow the OTP design principles,
but that they
follow them in situations where it is inappropriate. Unfortunately it takes
a while before you
know which approach is best. You have to code up a solution to a problem
with and without
the OTP libraries. For example write a server using gen_server and without
gen_server and see
which is best. Note that most books start with how to write a server
*without* gen_server.

Writing a statefull server *without* gen_server is really easy:

loop(State) ->
    receive
        {From, F} ->
             {Reply, State1} = F(State),
             From ! {self(), Reply},
             loop(State1)
    end.

With

rpc(Pid, Q) ->
      Pid ! {self(), Q},
      receive
           {Pid, Reply} ->
                 Reply
      end

The above code is basically all that gen_server does. gen_server just adds
a few goodies to stop
you shooting yourself in the foot.

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.

If it's a pure library there is absolutely no reason to do
application:start(blaa) etc. and make an
application for this - unless (and this is a big unless) - unless you want
to make a strictly compliant
OTP application and dynamically unload and reload the code at run time. In
the vast majority of cases
this is totally unnecessary and letting the dynamic code loader do it's job
will suffice.

In the very rare case that you actually do want to strictly manage your
code in an environment
that is designed to *never* be stopped then you need the application
structure - but this can be
added at the very end of the development processes.

Getting the process structure clear without regard to the OTP libraries is
far more important.

I've also see cases where code really does not fit the OTP behaviours, the
code is ugly and
unnatural - a clear sign that the underlying libraries should not be used.

The entire OTP infrastructure was designed for enterprise systems that
should *never* go down.

It was NOT designed for shell scripting, programs where taking the service
down
for a quick reboot is not a problem.

We can reboot an erlang system rather quickly (under 2 seconds, I guess) -
If you can live with this
then you can forget about release upgrades etc. Only very demanding systems
need the release upgrade
stuff.


>
> I think the needle could move here.
>
>
I think that something like e2 with less ceremony than OTP would be great.

There seems to be a gap:

    OTP => targeted for enterprise grade 24x7 stuff
    ?? => can take system out of service for a few seconds occasionally
    escripts => quick and dirty shell scripts

The ??? is not well served. Something like e2 with a quick-start and
packaging facility

Using OTP with all the release/application/supervisor stuff is building
enterprise grade
software for non-enterprise grade applications - which really is using a
battleship to crack a
walnut. Problem is we don't have a simple nutcracker.

Cheers

/Joe





> Garrett
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140213/775d736a/attachment.htm>