Comment by EdSchouten

I don’t want to come across as toxic myself, but I think that the toxicity that Evan sometimes has to endure from people in the community is somewhat self-inflicted.

Last year I wrote a web application in Elm. Even though I really liked the language and had lots of fun writing code, I noticed that the users effectively have to rely on Evan to make any meaningful progress. The ‘forkability’ of the project is very poor.

To give you a couple examples of that:

- Elm has a centralized package repository: https://package.elm-lang.org/. There is, however, no functionality in Elm to host your own registry, whether it is public or internal to your organisation. The monolithic compiler/build tool hardcodes the URL of this registry.

- Relatedly, there is no way you can easily fork a package and apply some changes, especially if you have no intent to host it through the official package collection. There is no way to say: “I want to use elm/http with this tiny local patch applied that I have sitting in my tree.”

- Some parts of Elm’s grammar/intrinsics are only permitted to be used by packages with author “elm” (i.e., the official core packages). This means that you cannot fork, say, elm/bytes to yourname/bytes and make local changes, as it can no longer be built.

Because of this, the maintainers of Elm don’t just decide what goes into the tree, they effectively also decide what users may do on their end. They are the folks sitting behind the master control panel and people filing issues/pull requests rely on them to push the buttons for them. I can understand why this causes friction within the community.

Note that this was my experience using Elm early 2019 (January-April). It may well be that Elm improved in these areas since.