<story><title>Hotswapping Haskell</title><url>http://simonmar.github.io/posts/2017-10-17-hotswapping-haskell.html</url></story><parent_chain><item><author>teraflop</author><text>I don&amp;#x27;t want to knock the technical achievement here -- it&amp;#x27;s a cool hack -- but I&amp;#x27;m really surprised that it was deemed to be the best choice for a production system.&lt;p&gt;In the first place, &amp;quot;we can&amp;#x27;t compile our code on every change because it takes too long&amp;quot; is a really awful situation to be in. Are developers not building and testing their changes before deploying them? Can Facebook not afford a continuous integration system that can run builds in parallel? It sounds like this problem is only happening because the application is a giant monolith, but for some reason splitting it up would slow down development even more... I&amp;#x27;m not sure I buy that reasoning.&lt;p&gt;The article says that &amp;quot;Haskell’s strict type system means we’re able to confidently push new code knowing that we can’t crash the server&amp;quot;, which is a real stretch. In addition to all of the usual ways a computation can diverge, this hot-swapping system adds a whole new variety of failure modes. The article talks about how the code needs to be carefully audited to prevent memory leaks, but it doesn&amp;#x27;t even mention the weird things that can happen when mutable state is preserved across code modifications. Debugging is a pain when your data structures can get into states that aren&amp;#x27;t reachable with any single version of the code. (This is a well-known issue in Linux kernel live-patching, for instance.)</text></item></parent_chain><comment><author>JonCoens</author><text>I should have emphasized the speed of deployment being a first order concern more. We certainly can (and do) build our code for every change, but not at the speed that we want to be updating.&lt;p&gt;We use a monorepo for all of the benefits it has, and deploying fast business logic updates this way helps mitigate one of its downsides (particularly when you&amp;#x27;ve maximally parallelized the build). I&amp;#x27;ve found &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;danluu.com&amp;#x2F;monorepo&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;danluu.com&amp;#x2F;monorepo&amp;#x2F;&lt;/a&gt; to give a quick overview of how  chopping up the repo would have separate downsides.&lt;p&gt;The section about &amp;quot;Sticky Shared Objects&amp;quot; speaks directly to mutable state across code modifications, just with a Haskell-minded focus.</text></comment>
<story><title>Hotswapping Haskell</title><url>http://simonmar.github.io/posts/2017-10-17-hotswapping-haskell.html</url></story><parent_chain><item><author>teraflop</author><text>I don&amp;#x27;t want to knock the technical achievement here -- it&amp;#x27;s a cool hack -- but I&amp;#x27;m really surprised that it was deemed to be the best choice for a production system.&lt;p&gt;In the first place, &amp;quot;we can&amp;#x27;t compile our code on every change because it takes too long&amp;quot; is a really awful situation to be in. Are developers not building and testing their changes before deploying them? Can Facebook not afford a continuous integration system that can run builds in parallel? It sounds like this problem is only happening because the application is a giant monolith, but for some reason splitting it up would slow down development even more... I&amp;#x27;m not sure I buy that reasoning.&lt;p&gt;The article says that &amp;quot;Haskell’s strict type system means we’re able to confidently push new code knowing that we can’t crash the server&amp;quot;, which is a real stretch. In addition to all of the usual ways a computation can diverge, this hot-swapping system adds a whole new variety of failure modes. The article talks about how the code needs to be carefully audited to prevent memory leaks, but it doesn&amp;#x27;t even mention the weird things that can happen when mutable state is preserved across code modifications. Debugging is a pain when your data structures can get into states that aren&amp;#x27;t reachable with any single version of the code. (This is a well-known issue in Linux kernel live-patching, for instance.)</text></item></parent_chain><comment><author>elihu</author><text>It kind of sounds like they&amp;#x27;re running into some limitations of GHC: it tends to take a long time to compile stuff, and it tends to generate some very big binaries.  For most applications, those aren&amp;#x27;t major problems but in their use case (hundreds of thousands of lines of code deployed to many servers) it is an issue so they&amp;#x27;re working around it.  That allows them to keep working in the language they prefer and are productive in, which is great.&lt;p&gt;Improving GHC compile times and reducing the binary size would be better, but presumably a lot of work has already gone into those problems and if it were easy someone would have done it by now.  As for myself, I really like using Haskell and I&amp;#x27;m glad whenever I hear about it being used in industry.</text></comment>