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

[Tristan Sloughter]

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 :)



On Thu, Feb 13, 2014, at 01:43 PM, Joe Armstrong wrote:




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

On Thu, Feb 13, 2014 at 12:15 PM, Joe Armstrong <[2]erlang@REDACTED>
wrote:

>

> On Thu, Feb 13, 2014 at 10:51 AM, Garrett Smith <[3]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


_______________________________________________

erlang-questions mailing list

[4]erlang-questions@REDACTED

[5]http://erlang.org/mailman/listinfo/erlang-questions

--
Tristan Sloughter
tristan.sloughter@REDACTED

References

1. mailto:g@REDACTED
2. mailto:erlang@REDACTED
3. mailto:g@REDACTED
4. mailto:erlang-questions@REDACTED
5. http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140213/65269e9d/attachment.htm>