Hacker News new | past | comments | ask | show | jobs | submit login

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.

Elm helps significantly with the latter.

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.

> Functional programming helps significantly with the latter.


So elm gives you plenty of time to sit around being completely blocked by conceptual/technical bugs that no one can solve.

The point I took from it was "These issues are valid, but in some cases there are benefits that outweigh them".

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact