| HN Mirror

My best reference for links would be the Slack logs from the job where I was using Elm full-time, but I'm not at that job anymore. If you're interested I would recommend trawling the issue trackers for the elm and elm-lang GitHub orgs as well as checking out the Elm subreddit and Discourse. Threads which discuss the limitations of the way the project currently operates or native JS workarounds to issues are often locked or moderated on those forums, however.

Off the top of my head, a couple of the compiler issues we worked around were case statements on a tuple causing non-linear increases in compilation time and the compiler hanging indefinitely when trying to infer certain types from our GraphQL library (which is an awesome lib; check out dillonkearns/graphqelm if you want to see Elm at its most useful). We also ran into a case rendering live-updating graphs where Elm would stack overflow after a certain number of internal messages.

As far as features, only a small portion of browser functionality is available in Elm and many of the integrations that do exist are not as complete as you might expect coming from another ecosystem. For instance the only way to do SPA navigation is to add explicit click event bindings and message handlers for every link. The port-based JS interop functionality is great for many use-cases, but we found it pretty awkward for others. A couple of these cases were blob file uploads and calling + reacting to `window.confirm`. The JS code additions to enable these features within Elm are very simple, but third-party libs can't include JS and it's unlikely to get a PR acknowledged much less accepted to anything first-party, so people end up hacking together their own fixes for lots of little issues in isolation. And the ability to do JS workarounds is apparently being curtailed even further in the upcoming release.

Some of the issues we had will be fixed with the release of 0.19 (namely, the compilation time issues and the SPA nav), but those fixes come along with a slew of breaking changes and after nearly two years since the last release. Information about the contents and development of that version has only started coming out in a meaningful way in the last couple of months. Up until that point it was basically rumor and hearsay, and we spent a lot of time wondering how we would justify to the rest of the company having made a big commitment to a seemingly abandoned language.

Overall I have fairly nuanced feelings about Elm which are difficult to communicate in this context. It's one of my favorite languages and I often feel very productive using it. I think it's an great achievement as a piece of technology and I agree with almost all of the design tradeoffs it makes. But I think if the project is meant to be used in serious contexts — a question which I should not even have to wonder about — then it has grown beyond the scope that one person can manage on their own. Evan has actively resisted enlisting and empowering the community to help realize his vision for the project and solve their own problems, and I think there is plenty of evidence that that is a worthwhile and feasible goal. Elixir is my go-to example for a project that does a great job at this and has benefited significantly from it.