<story><title>A Brief Guide to OTP in Elixir</title><url>https://serokell.io/blog/elixir-otp-guide</url></story><parent_chain><item><author>tlack</author><text>What you said is rarely stated in public, but I&amp;#x27;ve often felt it too: OTP obscures the underlying beauty of the Erlang platform.&lt;p&gt;OTP is well engineered of course, but the basic notion of the spawn -&amp;gt; receive -&amp;gt; loop cycle is so clean and illuminating that I wish newbies would hold out before learning OTP sometimes.&lt;p&gt;It&amp;#x27;s natural to think of case-specific abstractions around the primitives that are more germane to the domain at hand than OTP&amp;#x27;s.</text></item><item><author>pmontra</author><text>&amp;gt; In real life, we don’t need to write code with receive do loops. Instead, we use one of the behaviours created by people much smarter than us.&lt;p&gt;I make more than half of my income from Elixir. That said, 
the naive receive loop is much easier to understand than any of the GenServer examples. They pollute the module logic with all that handle_* boilerplate. I believe that neither Erlang nor Elixir got the right abstraction there. Method definition in any OO language is easier to understand. At least Elixir should have taken Agent and made it an invisible part of the language. All those calls to Agent in this example &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;elixir-lang.org&amp;#x2F;getting-started&amp;#x2F;mix-otp&amp;#x2F;agent.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;elixir-lang.org&amp;#x2F;getting-started&amp;#x2F;mix-otp&amp;#x2F;agent.html&lt;/a&gt; are still boilerplate.</text></item></parent_chain><comment><author>oaferlanger</author><text>OTOH every decent erlang book or tutorial I&amp;#x27;ve ready, from Armstrong&amp;#x27;s book[1] to Learn You Some Erlang[2] to Erlang and OTP in Action[3] and others all start off by introducing primitives like spawn, message sending , and receive.&lt;p&gt;They then introduce OTP and explain all the cases it handles.&lt;p&gt;I&amp;#x27;ve never read a book or tutorial on OTP that just starts with OTP. In fact (a bit tangetially) whenever I encounter abstractions where I don&amp;#x27;t already understand the primitives I have a very difficult time. Maybe that&amp;#x27;s just the way my brain is wired though. I have a terrible time with OO programming for that reason. I much prefer a separation of functions and data because it&amp;#x27;s much easier for me to reason about what is happening.&lt;p&gt;Anyway, I agree that programmers should start with the primitives, but I&amp;#x27;ve never seen anyone really teach OTP any other way.&lt;p&gt;Edit: also there are tools such as Erlang.mk[4] by Loïc Hoguin[5] that will handle a lot of the boilerplate for OTP projects and building releases, though it&amp;#x27;s good to do it manually at least once while learning.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;pragprog.com&amp;#x2F;titles&amp;#x2F;jaerlang2&amp;#x2F;programming-erlang-2nd-edition&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;pragprog.com&amp;#x2F;titles&amp;#x2F;jaerlang2&amp;#x2F;programming-erlang-2nd...&lt;/a&gt;&lt;p&gt;[2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;learnyousomeerlang.com&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;learnyousomeerlang.com&amp;#x2F;&lt;/a&gt;&lt;p&gt;[3] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.manning.com&amp;#x2F;books&amp;#x2F;erlang-and-otp-in-action&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.manning.com&amp;#x2F;books&amp;#x2F;erlang-and-otp-in-action&lt;/a&gt;&lt;p&gt;[4] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;erlang.mk&amp;#x2F;guide&amp;#x2F;index.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;erlang.mk&amp;#x2F;guide&amp;#x2F;index.html&lt;/a&gt;&lt;p&gt;[5] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;ninenines.eu&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;ninenines.eu&amp;#x2F;&lt;/a&gt;</text></comment>
<story><title>A Brief Guide to OTP in Elixir</title><url>https://serokell.io/blog/elixir-otp-guide</url></story><parent_chain><item><author>tlack</author><text>What you said is rarely stated in public, but I&amp;#x27;ve often felt it too: OTP obscures the underlying beauty of the Erlang platform.&lt;p&gt;OTP is well engineered of course, but the basic notion of the spawn -&amp;gt; receive -&amp;gt; loop cycle is so clean and illuminating that I wish newbies would hold out before learning OTP sometimes.&lt;p&gt;It&amp;#x27;s natural to think of case-specific abstractions around the primitives that are more germane to the domain at hand than OTP&amp;#x27;s.</text></item><item><author>pmontra</author><text>&amp;gt; In real life, we don’t need to write code with receive do loops. Instead, we use one of the behaviours created by people much smarter than us.&lt;p&gt;I make more than half of my income from Elixir. That said, 
the naive receive loop is much easier to understand than any of the GenServer examples. They pollute the module logic with all that handle_* boilerplate. I believe that neither Erlang nor Elixir got the right abstraction there. Method definition in any OO language is easier to understand. At least Elixir should have taken Agent and made it an invisible part of the language. All those calls to Agent in this example &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;elixir-lang.org&amp;#x2F;getting-started&amp;#x2F;mix-otp&amp;#x2F;agent.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;elixir-lang.org&amp;#x2F;getting-started&amp;#x2F;mix-otp&amp;#x2F;agent.html&lt;/a&gt; are still boilerplate.</text></item></parent_chain><comment><author>jeremyjh</author><text>&amp;gt; spawn -&amp;gt; receive -&amp;gt; loop cycle is so clean and illuminating that I wish newbies would hold out before learning OTP sometimes&lt;p&gt;Yes it is neat and its fun to play with but it isn&amp;#x27;t usually something you want to use in production code. In production code it is important to have processes linked correctly so that errors propagate to callers. GenServer.call handles this for you, and also clarifies intent (blocking call to another process that must respond or fail).</text></comment>