I've used Elm professionally for about a year, having done full rewrites of both a bloated React/Redux SPA and a map data visualizer with complex JS interop usi

I've used Elm professionally for about a year, having done full rewrites of both a bloated React/Redux SPA and a map data visualizer with complex JS interop using ports to Leaflet, AWS Cognito, etc. Luke Plant's blog post doesn't at all reflect my experiences with Elm or my feelings about the core team. For those not privy to the Elm tea, a brief primer: this blog post is primarily concerning a months-old issue regarding the removal of the ability to use native modules, which are effectively patches to the Elm runtime[1] which circumvent the core features of the language that provide its greatest strengths: a genuinely helpful compiler and ironclad runtime guarantees (still have yet to encounter a production runtime error that wasn't on the JavaScript side of things!) This "feature" (used loosely) was largely undocumented, always verboten from distribution in user packages, and never intended as anything more than a stopgap measure in extremely rare cases.[2] It was /officially/ not a core language feature intended for widespread usage, and consistently advised against by the Elm team. The removal of native modules was spoken about publicly months before the breaking upgrade. It came as no surprise to me. As an engineer who tries really hard to be responsible, I do not build software which relies on features which are advertised as 'do not use unless absolutely necessary' and are soon-to-be deprecated unless I'm willing to accept the inherent risk of doing so. The core Elm team was, in my opinion, extremely communicative, well-reasoned, and thoughtful in this change and in others, despite the inconvenience to a small subset of people. For each feature discussed in Luke's post, there is an accompanying Discourse thread[3], discussion on Google groups, Github gists[4], etc., that carefully lays out the reasoning, and carefully consider the scope of a change (in the instance of the removal of custom operators, the Elm team analyzed the package ecosystem and determined less than 5% of packages were affected)[4]. I won't cover the moral arguments around the obligations of open source maintainers as this has been covered ad nauseam with the Clojure and Rust fiascos of a similar sort - though I personally believe maintainers don't owe anyone anything, and I try to treat all free software graciously, as a precious gift, lucky to receive it at all. I will say that Elm's somewhat slow, closed BDFL-ish governance is well-documented as well[5, 6], available to all who seek to understand the Elm development process and decide for themselves if this is an ecosystem to hitch their wagon to. Of course the Elm maintainers get to patch their own runtime with native modules, because they are implementing core parts of the language, it's practically tautological. That users living in userland cannot do it is not unfair; it's a language design feature. What Luke seems to see as a stifling of an open community by the closure of issues and deletion of posts on the Discourse is often basic organizational maintenance to handle redundancies. Conversations around these issues have happened for months and in some cases years, and decisions have been made. They may not be to everyone's tastes. That should be just fine! If someone went to Famous Amos Cookies on Discourse, Slack, their mailing list, and opened a Github issue and PR suggesting this genius idea they just had, it's so good, wait for it - an oatmeal cookie without raisins! - I hope they would clean it up, close the issue, delete my posts, etc., for their own sanity. Not to mention that the opening to Luke's opus here is an admission of his own rudeness to the Elm team on most of these fora. Of course the relationship with maintainers will be strained with this kind of behavior. There are critiques of Elm, to be sure. The pace of releases is somewhat slow, custom operators might be nice for 3rd party parsing libraries, it might be cool to have a PR merged in to get that fuzzy feeling only OSS contributors get. But you cannot reasonably argue that Elm's team has been unfair, discriminatory, uncommunicative, or arrogant (pathos, so much pathos here!). I don't generally post comments anywhere, but articles like this are irresponsible and damaging not just to the well-being of maintainers who are being generous with their time trying to make something with great care, but to people (like many top level commenters here) who might have tried Elm but won't due to an inside baseball post from a spurned developer. It makes me actually sad, like want-to-cry sad. [1] https://newfivefour.com/elm-lang-basic-native-module.html https://newfivefour.com/elm-lang-basic-native-module.html (any somewhat experienced Elm developer will get nervous looking at this trivial example and immediately see what might break) [2] https://groups.google.com/forum/#!msg/elm-dev/1JW6wknkDIo/H9ZnS71BCAAJ https://groups.google.com/forum/#!msg/elm-dev/1JW6wknkDIo/H9... (2015!) [3] https://discourse.elm-lang.org/t/native-code-in-0-19/826 https://discourse.elm-lang.org/t/native-code-in-0-19/826 [4] https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc76b1 https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc7... [5] https://www.youtube.com/watch?v=o_4EX4dPppA https://www.youtube.com/watch?v=o_4EX4dPppA [6] https://github.com/elm/projects/blob/master/roadmap.md https://github.com/elm/projects/blob/master/roadmap.md