I wrote some code that iteratively would have just taken a while to run, but because Haskell wasn&#x27;t using true tail recursion, it ran out of stack space.<p>I also read a paper that talked about extensive research into optimizing a convolutional network algorithm in Haskell, if I remember correctly. The algorithm even used mutable data structures for speed (because <i>of course</i> you need data to be mutable for speed). Roughly speaking, if you ran it on 16 CPUs, it was <i>only</i> 4x slower than the C algorithm running on one CPU. And Amdahl&#x27;s Law [1] (as well as the graph in the article) hints that it may never actually be faster than the single CPU C version, no matter how many CPUs you split it onto, because of the overhead of sending the data around.<p>When people claim &quot;immutability makes it easier to run on more threads, which is the future of optimization!&quot; I just want to cringe. Immutability kills most performance enhancements you can possibly make on nontrivial code, even considering a single thread, having <i>all</i> your data be immutable does nothing at all to improve threading, and forcing all data transferred to another thread to be immutable kills a whole category of optimization.<p>When dealing with large amounts of data, you save <i>tons</i> of time by not copying it around.<p>&#x2F;rant<p>Sorry. I&#x27;ve been listening to too many people talk about Haskell like it&#x27;s an amazing silver bullet that will solve all of our problems. But There Is No Silver Bullet. Really.<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Amdahl&#x27;s_law" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Amdahl&#x27;s_law</a>