<story><title>Concurrent Programming, with Examples</title><url>https://begriffs.com/posts/2020-03-23-concurrent-programming.html?hn=1</url></story><parent_chain><item><author>Random_ernest</author><text>The article is very nice, thanks a lot for it. Especially since I hear the word concurrency and parallelism often thrown around without any distinction.&lt;p&gt;Very off topic, but I have read several times the argument that the rise of functional programming is due to it&amp;#x27;s easy concurrency (since functions don&amp;#x27;t have side effects) and that concurrency becomes more and more important due to moores law being dead (i.e. we can&amp;#x27;t scale the hardware up, we have to add cores to our processors).&lt;p&gt;Could someone with more experience comment on that? Is concurrency really easier in functional languages and is the rising importance of concurrency a valid reason to look into functional programming?</text></item></parent_chain><comment><author>clarry</author><text>&amp;gt; Is concurrency really easier in functional languages and is the rising importance of concurrency a valid reason to look into functional programming?&lt;p&gt;I think it depends on who&amp;#x27;s writing the code.  A little bit of shared mutable state here and there isn&amp;#x27;t gonna kill you, but if the program&amp;#x27;s architecture is poor, that&amp;#x27;ll blow up and spread everywhere and the next thing you know is you&amp;#x27;re spending half your time worrying about data races, deadlocks, and a locking nightmare.&lt;p&gt;Shared-nothing architectures fix that; your synchronization will happen over a narrow range of well defined primitives (e.g. message queues), though this doesn&amp;#x27;t prevent race conditions.&lt;p&gt;Functional programming that encourages pure functions &amp;amp; immutable state is a bit of a straight jacket that keeps you from making a mess that blows up.  I think it helps, and I wish $stuffAtWork were written in such a language because I&amp;#x27;m tired of wrestling with terrible architecture (that I&amp;#x27;m not really allowed to fix, given the time constraints).&lt;p&gt;The other thing that makes a difference is what your problem looks like.  Sometimes concurrency is absolutely trivial, like dispatching sections of an array for threads to perform (independent) compute on, and come back with a result.  Sometimes it&amp;#x27;s way more complicated...</text></comment>
<story><title>Concurrent Programming, with Examples</title><url>https://begriffs.com/posts/2020-03-23-concurrent-programming.html?hn=1</url></story><parent_chain><item><author>Random_ernest</author><text>The article is very nice, thanks a lot for it. Especially since I hear the word concurrency and parallelism often thrown around without any distinction.&lt;p&gt;Very off topic, but I have read several times the argument that the rise of functional programming is due to it&amp;#x27;s easy concurrency (since functions don&amp;#x27;t have side effects) and that concurrency becomes more and more important due to moores law being dead (i.e. we can&amp;#x27;t scale the hardware up, we have to add cores to our processors).&lt;p&gt;Could someone with more experience comment on that? Is concurrency really easier in functional languages and is the rising importance of concurrency a valid reason to look into functional programming?</text></item></parent_chain><comment><author>Athas</author><text>Concurrency is all about simultaneous effects.  A language like Haskell is nice enough because it makes effects explicit, so you at least know where things can go wrong, but if you have a bunch of concurrent effectful Haskell threads running at the same time, you have the usual issues with nondeterminism.  Functional languages to tend to emphasize higher-level concurrency patterns than old-school shared mutable state, so in practice it works OK.&lt;p&gt;Specifically, concurrent Haskell &lt;i&gt;is&lt;/i&gt; good and also quite fast.  It doesn&amp;#x27;t quite compare to Erlang in the concurrency department although the languages are very different in other ways, so there are reasons to prefer Haskell anyway.  I think this shows that just having a functional language that emphasizes effect-free programming is not sufficient.  If you want a &lt;i&gt;good&lt;/i&gt; concurrent language, then you have to design it like that, and not simply rely on the absence of shared mutable state.&lt;p&gt;In practice, people write massively concurrent systems all the time, in the form of dynamic web sites that handle many concurrent requests, and synchronise access to a shared mutable state via a transactional database of some kind.  These don&amp;#x27;t depend on fancy languages, but on a rigid architecture that tries to isolate synchronisation issues in the web server and database components.&lt;p&gt;While this article is about concurrency, I&amp;#x27;ll also add a note on parallelism: Parallel functional programming has IMO not been shown to work well in practice.  While it is trivial to parallelise more or less any pure functional program &lt;i&gt;correctly&lt;/i&gt;, it is very hard to actually gain meaningful speedup from it.  The single point of parallelism is performance, and most current implementations of functional languages (including &lt;i&gt;all&lt;/i&gt; general purpose functional languages I know of) simply have too many bottlenecks or pitfalls to scale for &lt;i&gt;computational work&lt;/i&gt; as well in practice as one might expect in theory.  For example, concurrent Haskell is fast because most of the actual work tends to be IO and GHC has an excellent parallel IO manager and scheduler, while parallel Haskell is hampered by, among other things, a slow garbage collector.</text></comment>