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

Joe Armstrong erlang@REDACTED
Thu Feb 13 19:15:54 CET 2014


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.

Supervisors are *easily* made with a combination of links/monitors and
trapping exits.

OTP was designed for teams of programmers, so that they would all write
their code the same
way and use common tools for code loading, error logging, supervision and
so on.

There is absolutely nothing stopping you from supervising and restarting
programs using
spawn_link and trapping exits.

The relationship between Erlang and OTP is like C and unix. Unix is an OS
written in C.
OTP is some middleware written in Erlang.


> Supervisors are gen_servers btw.
>
> If you think OTP is optional, look at the first two lines of kernel.erl:
>
>     -module(kernel).
>     -behaviour(supervisor).
>

But you don't need to load kernel.erl to run erlang programs - OTP needs to
load kernel.erl
My stand-alone system does not need this. The only *critical* modules are
error_handler.erl
and lists.erl


>
> Historically, OTP libraries came after Erlang the language, of course,
> but this so called OTP "framework" is now endemic to Erlang.
>

Yes - there were two other middlewares *before* OTP


>
> What sucks IMO is that OTP is treated as "advanced" by the community
> and by book authors. I understand the history of this, but there's a
> cost: programmers delay learning core Erlang principles of
> *applications* -- i.e. supervisor trees -- because it's not taught up.
> It's also incredibly complicated, if you don't use e2.
>

It's not incredibly complicated :-)

Applications and supervisor trees are not core concepts of Erlang - Erlang
(the language)
has not a clue what an application or a supervision tree is. Applications
and supervisors are
core concepts of OTP not Erlang.


>
> The irony is that *advanced* Erlang programmers can get away
> programming outside the OTP guard rails. Beginners should not even
> consider doing this until they understand why OTP works and why they
> should deviate.
>

No - beginners should start with spawn and spawn_link then learn to trap
exits
and then learn that they can replace a lot of simple boilerplate code with
the
OTP equivalents.


>
> e2 helps, a lot.
>
> The whole point of e2 is to simplify the correct use of OTP -- letting
> programmers *start* with applications, supervisors and gen_servers (in
> e2 they're called services and tasks -- simple huh). I know it's
> controversial, but it's controversial to those who have been teaching
> Erlang while this stuff was being baked. I don't run into new learners
> who object to starting with OTP using e2 (though maybe they're just
> being polite -- if you're out there and had problems learning with e2,
> please drop me a line, or yell at me here).
>

Actually you could layer e2 on top of a primitive bootstrap (read my book
for details).


>
> I agree wholeheartedly with Pieter. It's just Erlang. Keeping the term
> OTP is a historic vestige. We're used to it, but it's a dead weight
> that adds only confusion.
>

I think the problem with the name OTP is that is embedded in a load of books
and documentations. Change the names and you invalidate the documentation.

Change the names and you lose backwards compatibility

Cheers

/Joe


>
> The Ruby / Rails comparison is not accurate. It's more like Rails 1.0
> / Rails 2.0.
>
> Sadly though, I just don't see "OTP" going away because there's a
> trickle of noise from this list :|
>
> I make videos to cope.
>
> On Thu, Feb 13, 2014 at 2:54 AM, Ivan Uemlianin <ivan@REDACTED> wrote:
> > On 13/02/2014 08:13, Pieter Hintjens wrote:
> >>
> >> ... (a) stop using OTP as a
> >> confusing and needless synonym for Erlang, ...
> >
> >
> > Is that what OTP is used as?  I thought OTP was a set (or framework, or
> > platform) of libraries (behaviours, supervision, etc.) that facilitate
> the
> > development of highly scalable and reliable applications (telecoms-grade
> > scalability and reliability you might say).  AFAIK it's open-source.
> >
> > Yes, let's rename it to something that more closely reflects what it
> really
> > is.  How about the "Open-source Telecoms-grade reliability and
> scalability
> > Platform"?
> >
> > Ivan
> >
> >
> > --
> > ============================================================
> > Ivan A. Uemlianin PhD
> > Llaisdy
> > Speech Technology Research and Development
> >
> >                     ivan@REDACTED
> >                      www.llaisdy.com
> >                          llaisdy.wordpress.com
> >               github.com/llaisdy
> >                      www.linkedin.com/in/ivanuemlianin
> >
> >                         festina lente
> > ============================================================
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140213/04817ba9/attachment.htm>


More information about the erlang-questions mailing list