<story><title>The Erlang Shell</title><url>https://medium.com/p/ab8d8bec3972</url></story><parent_chain><item><author>phamilton</author><text>I&amp;#x27;m another recent Erlang convert (though I&amp;#x27;m still trying to get used to the paradigm and ecosystem). There are a few concepts that haven&amp;#x27;t quite clicked for me.&lt;p&gt;I come from a Rails background. While Erlang&amp;#x27;s hot code reloading and the ability to attach to running nodes is cool, I am not quite able to connect the dots on how this is useful. In Rails, a process is short-lived by design (the lifecycle of a request). Attaching to a process is useless, but the Rails console essentially gives you an isolated process to inspect production code and data. I don&amp;#x27;t see how extending that to an existing process would be useful.&lt;p&gt;So, challenging my assumptions, perhaps short-lived processes aren&amp;#x27;t the best approach for a web service. Perhaps that&amp;#x27;s the paradigm in Rails because Ruby lacks the tooling to make a long-lived process easy to maintain. If a long-lived process is as easy to maintain as short-lived processes, then suddenly new architectures open up. How are these architectures different? What are the benefits? What are some examples?</text></item></parent_chain><comment><author>davidw</author><text>&amp;gt; In Rails, a process is short-lived by design (the lifecycle of a request)&lt;p&gt;Yes and no.  Rails processes are so huge that they are loaded up and kept around between requests.  Erlang processes (which are not unix processes!) are much smaller and lighter.  One Erlang program can handle tons of concurrent, always open requests, whereas Rails just isn&amp;#x27;t cut out for that.&lt;p&gt;As to what Erlang is good for, I think its sweet spot with web stuff is where you need a lot of always open connections, such as with web sockets.&lt;p&gt;I&amp;#x27;m a fan of Erlang, but for most SaaS kinds of startuppy things, am not sure it&amp;#x27;s a good fit: you get so many more tools packaged up and easy to use for you with Rails that unless you know Rails does not work for you, I would almost always choose Rails.</text></comment>
<story><title>The Erlang Shell</title><url>https://medium.com/p/ab8d8bec3972</url></story><parent_chain><item><author>phamilton</author><text>I&amp;#x27;m another recent Erlang convert (though I&amp;#x27;m still trying to get used to the paradigm and ecosystem). There are a few concepts that haven&amp;#x27;t quite clicked for me.&lt;p&gt;I come from a Rails background. While Erlang&amp;#x27;s hot code reloading and the ability to attach to running nodes is cool, I am not quite able to connect the dots on how this is useful. In Rails, a process is short-lived by design (the lifecycle of a request). Attaching to a process is useless, but the Rails console essentially gives you an isolated process to inspect production code and data. I don&amp;#x27;t see how extending that to an existing process would be useful.&lt;p&gt;So, challenging my assumptions, perhaps short-lived processes aren&amp;#x27;t the best approach for a web service. Perhaps that&amp;#x27;s the paradigm in Rails because Ruby lacks the tooling to make a long-lived process easy to maintain. If a long-lived process is as easy to maintain as short-lived processes, then suddenly new architectures open up. How are these architectures different? What are the benefits? What are some examples?</text></item></parent_chain><comment><author>e_proxus</author><text>If you want to develop web pages, don&amp;#x27;t do Erlang. If you want to do web services, do Erlang. I&amp;#x27;ve used both Ruby (Rails) and Python (trying to do concurrency with tornado, greenlets, gevent) and they just fell flat. You can do it, but it is incredibly messy and unstable (because there&amp;#x27;s so much work involved).&lt;p&gt;In Erlang, you would typically answer a web request in a new actor every time. Just as in Rails, running for example N number of threads serving one request each. Of course, in Erlang that number of actors can vary, which means your system will be more responsive and you&amp;#x27;ll have lower average latency. However, what differs mostly, is that in Erlang all those actors live inside one VM and you can have central actors managing things, collecting statistics, keeping global state, talking to databases &amp;#x2F; other services. This, I think, is the core strength of Erlang compared conventional single threaded &amp;#x2F; GIL systems.&lt;p&gt;A more concrete example would be to dynamically show the current request rate on a web page. You can just create an actor that gets a message from any other actor once they handle a request, and keeps track of how many such messages per second arrive. Then when rendering that web page, you just ask that actor for it&amp;#x27;s current value. Simple, beautiful, dynamic. No need for a database or any other central storage.</text></comment>