I think Bryan Cantrill is referring to both STM and M:N in the context of high performance applications (aka, the norm for him, since he&#x27;s a kernel engineer). In <i>that</i> sense, both of them do have problems.<p>Circa 2000, Solaris, Linux, and some (all?) BSDs had M:N threading, and all of them threw it away because there are numerous performance artifacts caused by two schedulers (OS and the M:N) conflicting with each other. Mr. Cantrill was there when this all happened, and even wrote a paper on it: ftp:&#x2F;&#x2F;ftp.cs.brown.edu&#x2F;pub&#x2F;techreports&#x2F;96&#x2F;cs96-19.pdf<p>This doesn&#x27;t affect Erlang as much simply because Erlang is <i>really</i> slow. I think of it as a waterline -- the lower the overhead of the language, the more likely you will run into the serious problems that M:N typically inflicts. E.g. priority inversion, and long and unpredictable latencies when the OS swaps out a thread that M:N wanted running.<p>As for Haskell and STM, all I know on the topic is that some pretty damn smart engineers at IBM spent a good while trying to make STM work <i>well</i>, and gave up. See this ACM article: <a href="https:&#x2F;&#x2F;queue.acm.org&#x2F;detail.cfm?id=1454466" rel="nofollow">https:&#x2F;&#x2F;queue.acm.org&#x2F;detail.cfm?id=1454466</a>. Perhaps Haskell managed to pull it off through the language restrictions it allows, but I’d like to see some compelling articles on that by engineers who know a thing or two; just because a language has STM doesn’t mean it does it well.<p>Honestly, I think your comments about M:N and STM are more revealing of your ignorance rather that Cantrill&#x27;s. While you might disagree with him, there’s sufficient literature to give his stance some legitimacy. Sweepingly calling his stance &quot;full of crap&quot; says a thing or two.