There&#x27;s no cognitive dissonance needed: popularity is simply not a strong indicator of quality. I&#x27;m not saying that &quot;popular things are bad&quot; but rather that &quot;popular things <i>can be</i> bad&quot; and that quality is mostly orthogonal to popularity. There&#x27;s no more conflict in saying that Go is bad despite its popularity any more than there is in saying that Big Macs are poor quality food. (Which are, of course, developed by leading minds at one of the largest food processing corporations in the world...)<p>There&#x27;s been some fascinating research in this regard, finding that things get popular based on social factors (namely the shape of the social graph) coupled with some amount of random change, largely removed from any intrinsic qualities of the thing in question[1].<p>Another annoying thing this article—and similar ones like it—does is conflate &quot;different&quot; and &quot;unfamiliar&quot; with &quot;complex&quot;. Even if you don&#x27;t understand it, the Haskell type system is <i>not</i> complex: it&#x27;s a slight elaboration of the lambda calculus which can be <i>fully</i> described on half a piece of paper with type theoretic notation which translates to <i>maybe</i> a page or two of prose. (Which is only needed to provide some general background information.) Haskell <i>really</i> does boil down to a simple kernel like this which is even used by the compiler (as an intermediate form called &quot;Core&quot;). Everything else is just syntax sugar, usually in transparent ways.<p>In a similar vein, the article conflates <i>simplicity of implementation</i> with <i>simplicity of language</i>. The two diverge as soon as you start caring about performance—performance breaks all abstractions. That&#x27;s the only reason GHC is complicated; writing an <i>interpreter</i> for Haskell is actually probably <i>easier</i> than Go because, again, it&#x27;s just the lambda calculus. That&#x27;s literally something we teach <i>freshman</i> in a general-purpose intro course (SICP[2]). It&#x27;s easier to understand what a Haskell program means because of this; it&#x27;s only harder once you start worrying about low-level optimization. The dynamic semantics of Haskell—what happens as an expression is evaluated—can largely be summed up in a <i>single</i> rule describing function application. That&#x27;s it! Even if you find it difficult, which is understandable, it is <i>not complex</i>; difficulty is as much a function of your background as anything else.<p>Popularity is a terrible way of evaluating programming languages on anything but their popularity. Simplicity of implementation <i>is not</i> simplicity in general. This article is decidedly unconvincing.<p>[1]: Here&#x27;s a nice summary with references to peer-reviewed studies: <a href="http:&#x2F;&#x2F;nautil.us&#x2F;issue&#x2F;5&#x2F;fame&#x2F;homo-narrativus-and-the-trouble-with-fame" rel="nofollow">http:&#x2F;&#x2F;nautil.us&#x2F;issue&#x2F;5&#x2F;fame&#x2F;homo-narrativus-and-the-troubl...</a><p>[2]: <i>The Structure and Interpretation of Computer Programs</i>, an book introducing CS still used at many universities and available free online: <a href="https:&#x2F;&#x2F;mitpress.mit.edu&#x2F;sicp&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mitpress.mit.edu&#x2F;sicp&#x2F;</a>