Despite the abrasive tone of this article, it is true that Elm misses a convenient level of abstraction (whether that be type classes, module functors or whatever).

I spent the first few weeks of my first Elm project fighting against the language, trying to emulate type classes, build abstractions, do things like I would in other languages and generally having a bad time. Eventually, and with slightly bad grace, I conceded to the current limitations of the language and did things the Elm way, accepting that sometimes things are bit boilerplatey and cumbersome.

Now my second large Elm project is currently in its first round of QA, and the difference to similar projects in Angular or React is striking. There are no (and I mean ZERO) runtime errors that have popped up during testing. When QA find a bug, its instantly clear exactly where in the codebase the problem is, and usually simple to fix. So far most serious issues have ended up ultimately being consequences of a poor choice of design/modelling that, when fixed, has ended up in a higher quality overall codebase.

Yes, things could be better, and I'm sure they eventually will be. We would all like the kind of abstractions you talk about in your article, but in my real-life experience it turns out that you don't need them to write powerful and high quality code.

And hey, when these kinds of abstractions do arrive I'll just refactor my code, and know that the compiler will tell me when its done. Imagine doing that in Javascript.