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

Garrett Smith g@REDACTED
Thu Feb 13 18:33:21 CET 2014


On Thu, Feb 13, 2014 at 11:15 AM, Anthony Ramine <n.oxyde@REDACTED> wrote:
> Replied online.
>
> --
> Anthony Ramine
>
> Le 13 févr. 2014 à 17:54, Garrett Smith <g@REDACTED> a écrit :
>
>> And my point is that the OTP distinction is confusing and non-helpful,
>> especially to learners. That you're resorting to technically pedantic
>> points here I think reinforces what I'm saying.
>
> Indeed that was pedantic. What isn't is that Erlang is a language and OTP is a set of tools. That was the point, they are separate things. Just like studying Java doesn't mean you will study the JDK.
>
> I can't count the number of beginners' questions I replied to on the IRC channel that were related to Erlang *only* and where OTP knowledge would not have helped at all.

I'm happy to wind this thread down, but I have the slighted irritation
that I haven't made myself clear.

Yes, the OTP behaviors and the scheme for wiring code into init and
process life cycle management are indeed separate from the language.
In fact, *all* of the core applications and modules can be separated.
And people on IRC can ask questions that don't touch on lots of
things.

What I'm talking about is how we communicate and present Erlang -- the
name, the brand, the core concepts.

Modules like inets, gen_tcp, proplists -- this list is very, very long
-- are things you can do without depending on your application.

Modules like gen_server and supervisor are things that you cannot, or
at least should not, do without. If you don't use them, it's a bad
idea, unless you're a guru rock star.

I don't think this is general knowledge -- many Erlang programmers
think of these essential OTP modules as optional, advanced things you
can tack on later once you have graduated to that level. This is plain
wrong, in *practice*, for people who want to write fault tolerant
Erlang programs.

So that's my beef. Now that I've said this like ten times in this
thread, I'll let it be.



More information about the erlang-questions mailing list