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

[Anthony Ramine]

Replied online.

-- 
Anthony Ramine

Le 13 févr. 2014 à 17:54, Garrett Smith <g@REDACTED> a écrit :

> On Thu, Feb 13, 2014 at 4:42 AM, Anthony Ramine <n.oxyde@REDACTED> wrote:
>> 
>> Le 13 févr. 2014 à 10:51, Garrett Smith <g@REDACTED> a écrit :
>> 
>>> 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.
>>> 
>>> Supervisors are gen_servers btw.
>>> 
>>> If you think OTP is optional, look at the first two lines of kernel.erl:
>>> 
>>>   -module(kernel).
>>>   -behaviour(supervisor).
>>> 
>>> Historically, OTP libraries came after Erlang the language, of course,
>>> but this so called OTP "framework" is now endemic to Erlang.
>> 
>> You just proved it's difficult to use Erlang without the stdlib. Erlang is still not OTP.
> 
> I didn't say that Erlang is OTP. My point is that treating "OTP" as
> something you learn outside of "Erlang" is not helpful.
> 
>> In fact, the kernel module isn't even a preloaded module, this means it is not a necessary thing to use Erlang. You could have your own Erlang/E2 if you wanted.
> 
> I'm not talking about esoteric details of how Erlang is bootstrapped.
> I'm not talking about what you *can* do with the libraries and
> tooling. I'm not talking about the language grammar, parsers, tool
> chain, etc.
> 
> I'm talking about what nearly 100% of all humans use when the use
> Erlang, which is a facility for starting a system of OTP applications.
> *Practically speaking* OTP is *endemic*.
> 
> 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.

>>> 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.
>>> 
>>> 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.
>>> 
>>> e2 helps, a lot.
>> 
>> OTP is a set of building blocks for concurrent and distributed systems.
>> 
>> Concurrency and distribution are advanced topics.
> 
> OTP doesn't help with concurrency and distribution. It's there to
> organize system start up and process life cycle. It's analogous to
> init and monitoring schemes in operating systems (e.g. systemd, runit,
> etc.)
> 
> If you don't care about how your code is started and managed while
> it's running, you might not about "OTP" -- or you might be a guru rock
> star. In either case, you're not typical.

It helps with startup, and concurrency, and distribution, cf. all the OTP generic behaviours.

Talking about init systems, an OS kernel without a systemd-like is not very useful, we still don’t conflate the two.

>> Thus OTP is an advanced topic.
>> 
>>> 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).
>> 
>> e2 is a leaky abstraction which you need to deviate from when you need more complex stuff; let's not add an infinity of layers on top of OTP.
> 
> All abstractions leak. And even with that, e2 actually is pretty tight.
> 
> The *only* time I don't use e2 is when I don't want to introduce it as
> a library dependency (e.g. within another small library like a
> database driver, etc)
> 
> Have you used e2? Did you run into a specific case that e2_process or
> e2_task didn't accommodate?
> 
> And *one thin layer* layer on top of on an interface that is begging
> to be simplified is certainly not an infinity.

No, I didn’t use e2 because I don’t think the OTP behaviours are an interface that is begging to be simplified.

>>> 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.
>> 
>> Erlang itself is dead weight to most in the industry, does that mean we should forgo Erlang altogether?
>> 
>>> The Ruby / Rails comparison is not accurate. It's more like Rails 1.0
>>> / Rails 2.0.
>> 
>> I have no idea how you would find this accurate.
>> 
>>> Sadly though, I just don't see "OTP" going away because there's a
>>> trickle of noise from this list :|
>> 
>> How do you know there isn't a silent majority who just doesn't care or wouldn't like the OTP team to spend time trying to rewrite history? That sounds quite a dismissal of the opposing opinion in this debate. In fact,  I have to admit I wouldn't have replied if not for that sentence.
> 
> I haven't seen a call for rewriting history.
> 
> The call is to stop using "OTP" as a meaningful term in the context of
> Erlang. You and Loïc have accurately pointed out that it's *possible*
> to separate a couple layers within Erlang that coincide with this
> Erlang/OTP division. But it's not *practical* and the practice of
> treating OTP compliance as something-to-learn-later is bad for Erlang,
> IMO.
> 
> I'd like to see an effort to simplify the code and process needed to
> write OTP compliant code. e2 is I think a reasonable first attempt at
> that. I would offer it as input to the process.

Any renaming creates a disconnection with the previous literature.

And I still don’t think OTP is a mess, the only thing missing to me is a way to continue work immediately after init (or from init with some kind of init_ack function to reply to the initial caller) without sending a message to itself.

>>> I make videos to cope.
>> 
>> I give value to historic facts and terminology to cope.
> 
> But as long as you cope. It's the most important thing.
> 
> Garrett