koolak82
koolak82
Nov 3 · 3 min read

Erlang or Erlang/OTP

Erlang/OTP is a concurrent language in my opinion. More rightly its an implementation of actor framework (I know). But my first line / definition was deliberate (and I still stand by it) because it’s a lnguage too. The path to actor implementation in Erlang goes through language hence the language and actor (concurrency) is pretty tied up. And that gives me nicely the definition.

Erlang/OTP is a concurrent language.

Now this could be debated all night long. And I don’t want to even somebody else say that I have an answer. These are just my views and opinions. And even if they are just adding fuel to the fire, so be it. That is not the intention, but I know I am not doing anything more than that also (hence the disclaimer).

So back to the topic. Why is Erlang and OTP should be seen together only and never seprate?

  • Reason #1: Erlang might be used without OTP in the wild but still that would be, I guess, 1% of the use case of Erlang and pretty advanced one. Now the big point here is that Erlang outside OTP doesn’t give much tools, hooks /agents, or what not to make those non-OTP applications. Some adventurous people would have tried it, but I would say they are very brave. They must have seen something very good with Erlang and something very wrong with OTP. Both of these have to be true. And if that is true I am not that smart or intelligent to comment on that.
  • Reason #2: Something of an extension of point #1 above. When Erlang starts it starts an OTP system too for itself (by default). Every distribution of Erlang/OTP does that. There aren’t many. So let’s say you go on and think of using Erlang without OTP, Erlang by itself will not help you. You won’t get shell and all. (May be I am totally wrong there and exaggerating a lot) but still I doubt there are as popular Erlang mods /distro (if I am right with naming) as the one universal Erlang/OTP. In comparison to let’s say Java where you could have probably much much more ways to play with it (now specially after Java 9+ and Graal) like let’s say a) choose JVM based language to start with b) choose GC to start with c) choose Graal d) choose JPMS modules to start with etc. Now the point was not to say Java is better than Erlang/OTP. It was not the point. At all. But take it just as a reverse logic / arguementing to prove a point. That was the purpose that’s it. May be I was able to convey my thoughts. Java too is very rigid in terms of arch. You will have source code -> byte code -> machine code in the end (similar to Erlang/OTP). And that proves the point in straight direction too that Eralng/OTP should be seen as one.
  • Reason #3: Probably the biggest reason of all. Erlang/OTP is pited as concurrent language (or lets call it framework as of now, at that start of this reason #3 and I will deny/disprove it it by the end of it). And the most important pieces of the concurrency bit are in OTP. That is the behaviour and supervisors. They are part of OTP. There is no other way of concurrency in Erlang/OTP (please help me if I am wrong), no threads, no fibres, no Reactive (Rx) etc. So, if the concurrency is the end goal (and it’s a nice end goal) Erlang/OTP is the medium not Erlang alone. Actor concurrency is a proven bit way of concurrency. Now I don’t know of much of pure actor model and impure actor model and whatever Erlang/OTP is. But it’s a proven model. Every (many) language has it. Be it Java, Python, may be Haskell too. So, if the end goal is nice one should not harp on the medium much. And the debate itself is futile whether it’s Erlang, OTP, or Erlang/OTP.

Now here you have it. Probably a rumbling sort of post. But a product of leisurely Sunday mind. Enjoy your somewhat more valauable Con-Currency now. Hope you all are more wealthy now. (Hope you got the pun!)

    koolak82

    Written by

    koolak82

    (Sphagetti) Javascript, (Bloated) Java .. in the middle, and (frightening, mysterious) DB at the back