<story><title>Why Erlang Matters</title><url>https://sameroom.io/blog/why-erlang-matters</url></story><parent_chain><item><author>mistercow</author><text>I&amp;#x27;ve been confused for some time as to why people get excited about green threads. From what I&amp;#x27;ve read, the main advantage seems to be that you can have threads on hardware that doesn&amp;#x27;t support threads natively, which is cool if you&amp;#x27;re on that kind of hardware. There&amp;#x27;s also some spin-up advantages I guess? But they don&amp;#x27;t get load-balanced across cores, right?&lt;p&gt;I feel like I&amp;#x27;m missing something important.</text></item><item><author>jeremyjh</author><text>There is one other. Haskell has green threads, a preemptive scheduler, and it has a pretty decent implementation of Erlang-inspired multi-node concurrency primitives and higher-level framework including supervisors, gen_server equivalent etc in the Cloud Haskell project. It does NOT have Erlangs deployment base and track record but it is still a very promising framework and very appealing if you like Haskell&amp;#x27;s type system.&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;haskell-distributed.github.io&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;haskell-distributed.github.io&amp;#x2F;&lt;/a&gt;</text></item><item><author>atemerev</author><text>AFAIK, Erlang is still (as of 2016) the only distributed actor model implementation with preemptive scheduler.&lt;p&gt;All other major implementations (including Akka) have cooperative scheduling, i.e. forbidding blocking code in actors. Erlang allows it. This is huge.&lt;p&gt;And actor supervision is the best way to write reliable systems. I have wrote some code in Akka without much effort and testing (streaming market data aggregation), and it is still running with a few years uptime.</text></item></parent_chain><comment><author>mbrock</author><text>Green threads aren&amp;#x27;t just a substitute for when you don&amp;#x27;t have system level threads. Instead, they&amp;#x27;re a way of structuring code that allows you to express highly concurrent programs without requiring the heavy overhead of launching and switching between operating system threads.&lt;p&gt;Linux switches between threads at some frequency, I think it used to be 100 Hz. It involves swapping out the process registers, doing some kernel bookkeeping, etc—this is called a &amp;quot;context switch&amp;quot; and it&amp;#x27;s quite costly. Also, Linux threads allocate at least one memory page (4 KB) for the stack. [If I&amp;#x27;m wrong about these details, please correct me!]&lt;p&gt;Basically, the cost associated with an operating system thread comes from the fact that it has to be isolated from other system threads on a low level... whereas language runtimes that offer green threads impose their own safety via language construction, e.g., Erlang processes can&amp;#x27;t reach in and mess with other processes memory (without C hacks).&lt;p&gt;So green threads can be much more efficient, but they require some care in the implementation, especially to support I&amp;#x2F;O, and to have fair and efficient load balancing, etc. Then you run N operating system threads to get balancing across cores, and distribute green thread work.</text></comment>
<story><title>Why Erlang Matters</title><url>https://sameroom.io/blog/why-erlang-matters</url></story><parent_chain><item><author>mistercow</author><text>I&amp;#x27;ve been confused for some time as to why people get excited about green threads. From what I&amp;#x27;ve read, the main advantage seems to be that you can have threads on hardware that doesn&amp;#x27;t support threads natively, which is cool if you&amp;#x27;re on that kind of hardware. There&amp;#x27;s also some spin-up advantages I guess? But they don&amp;#x27;t get load-balanced across cores, right?&lt;p&gt;I feel like I&amp;#x27;m missing something important.</text></item><item><author>jeremyjh</author><text>There is one other. Haskell has green threads, a preemptive scheduler, and it has a pretty decent implementation of Erlang-inspired multi-node concurrency primitives and higher-level framework including supervisors, gen_server equivalent etc in the Cloud Haskell project. It does NOT have Erlangs deployment base and track record but it is still a very promising framework and very appealing if you like Haskell&amp;#x27;s type system.&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;haskell-distributed.github.io&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;haskell-distributed.github.io&amp;#x2F;&lt;/a&gt;</text></item><item><author>atemerev</author><text>AFAIK, Erlang is still (as of 2016) the only distributed actor model implementation with preemptive scheduler.&lt;p&gt;All other major implementations (including Akka) have cooperative scheduling, i.e. forbidding blocking code in actors. Erlang allows it. This is huge.&lt;p&gt;And actor supervision is the best way to write reliable systems. I have wrote some code in Akka without much effort and testing (streaming market data aggregation), and it is still running with a few years uptime.</text></item></parent_chain><comment><author>hornetblack</author><text>One advantage is spinning up new green threads can be very quick. Starting a new Kernel thread requires at least 1 syscall.&lt;p&gt;For example: on a network service, you have 1 thread listening for new connections, when a new connection is made. It starts a new thread, which calls the handler. The listener thread then goes back to listening for new connections.&lt;p&gt;Now the advantages can depend on your green threading implementation. If a listener thread blocks on reading from Disk or a DB. Then the listener thread can still wait for new connections and other connection handlers can still operate. Making you network application responsive, without increasing latency on clone syscalls.&lt;p&gt;Of course you can achieve this in other ways.</text></comment>