I don't get it. The author didn't address his original concerns, he just said "Elm is awesome", which may be true, but isn't a rebuttal of his previous points, which are condensed here:
>You can go through the whole development lifecycle of the app and you’ll rarely encounter a situation where you can’t find a fix online in 5 seconds. Somebody else has already worked out the kinks. My strategy was flawless.
I suspect the missing connection is this: if you encounter a conceptual/technical bug with a popular language/framework, you can find a solution online quickly.
If you write buggy code (especially bugs that don't reveal themselves until live in production) it involves much, much more pain to fix those.
That's one of the points he raised, and I see the value now. However, the author also talks about the dangers that come from using lesser-known, using unstable languages (he mentions finding bugs in the compiler, segfaults, and so on), and he doesn't say how Elm solves them
The author does emphasise how complete and well-built the official Elm tools are, which kind of mitigates this concern. But I agree, the article doesn’t really spell out its reasoning.
> does emphasise how complete and well-built the official Elm tools are
It's not a good point. It's just unrealistic to rely on standard libraries, even if you're writing Scala or Python. Community size must be an important factor, even for Elm. It is highly unlikely that Elm is so perfect, that community size simply becomes irrelevant.
I think we can all agree that this article isn't finished at all.
Good point. I suspect to some degree it's mitigated by the fact that anyone attempting to re-implement (most of) Haskell must care about correctness a great deal, and having Haskell already in place limits the number of conceptual bugs.
Anyway, this is pure speculation on my part, I have yet to dive into either language.
If that also has the consequence of significantly less bugs in Elm libraries, you will also encounter much less of the former when using third-party libraries.
>You can go through the whole development lifecycle of the app and you’ll rarely encounter a situation where you can’t find a fix online in 5 seconds. Somebody else has already worked out the kinks. My strategy was flawless.