Why I’m Leaving Elm

Evan spends every Meetup exclusively focused on attendees who've no it's very little experience with the language, basically giving them a personal guided tour. In these sessions here is very kind and patient - and a skilled teacher.

Richard is friendly as well and does a great job communicating the vendors of Elm's design and how best to take advantage of it. He is also a senior practitioner who writes Elm on a daily basis.

NoRedInk is truly powered by Elm, and that has helped them hire very easily despite not having tons of cash to throw around (they make education software).

So at the end of the day, I've come to view them as true believers in a very particular vision for the language. It is compelling, especially when walked through it by Evan. But they have a lot personally on that vision.

In many ways, they view themselves as taking the long slow road to what will be the "UI language of the future". They want many people to try the language and see the benefits of immutability, purity, and declarative UI. They want people to follow their lead and use those principles in using Elm in their projects.

But in their eyes, Elm is not done. They have no interest in people coming in and suggesting that Elm should be something else. At times, that's lead to some rash behavior that looks bad. But as practical as Elm is for many projects it is not Pragmatic. And that turns people off.

And if it turns you off, I'd leave Elm off your list of choices for a language in your production projects...for now.

It is yet to be seen if Evan's vision will succeed in it's goal of making functional, declarative, strongly typed UI programming "mainstream". But he's proven that he is committed to that vision regardless of a large host of workaday engineers asking him to compromise in some way.

Maybe some day, custom operators come back. Maybe some day there will be type classes. But I can guarantee that day won't come until the vision is complete and you see Elm 1.0

PS: I fully empathize with the people turned off by this approach by the way, but I can't help but truly appreciate someone doggedly standing firm on their design principles and seeing it though despite it costing them an opportunity at widespread fame. I have no long term contact with the Elm core team, and no projects using Elm currently. Maybe when I see 1.0 :-)

Rather than compound problems with unnecessary incompetence and calling it functional and typed. The only thing typed I discovered is undefined incompetence from Elm to C++.

There is always an excuse to complicate problems when you are incompetent and invent useless languages.

Any decent library will describe the operator in its Haddock documentation, and most will export a named function with the exact same semantics and type.