Clients expressing doubt about choosing Elm

I believe you mean this discussion?

Re the “why doesn’t someone just fork it?” (and presumably continue development with a different governance and development attitude) question: It is not clear that one can get the level of quality and consistency that Elm has with a significantly different process.

Or in other words, everybody knows that “design by committee” is suboptimal, but we at the same time love to talk about “bus factor”.

1 Like

This code hangs forever and this bug has existed for years in Elm:

String.right 1 "🙈" |> String.toList

Honestly I don’t think that’s it.

  • Developing a language is hard work
  • Forking a project is hard work
  • Coordinating work with other contributors is hard work
  • Getting people to use your fork is hard work

Although I think there are plenty of people talented to do that hard work, I expect the main reason why it hasn’t been done is those people have complained and subsequently left the community at different times.

Forks (besides one-person forks) happen when a group of people with similar ideas on what the future of a project should be get together and start working. There’s no group of passionate people to make that fork happen, just a steady trickle of common complaints and attrition.


Rather than a fork, I think what Elm could benefit from is a release branch. Let me explain…

Suppose you are working on some software system that is undergoing an ongoing R&D phase. At some point its nearly ready and your sponsor is needing to find some customers and ship it to pay for all that R&D. At that point you maybe do some tidy up on the mainline, and then take a release branch. On the release branch you do the necessary preparation work to ensure the customer gets a polished product - like adjusting the look and feel, integrating it with Active Directory for the clients single sign-on, add some custom database fields, stuff like that.

When the customer starts using the software for real, they are bound to do things that you did not anticipate, so you will get a stream of bug reports coming back from them. You fix these on the release branch, but you also apply these patches back onto the mainline. If you are smart you also first write a test to demonstrate the bug, then fix it, and add the test to the regression pack so that the bug never comes back, if somehow its patch gets overlooked on some branch (happened to me once, got called out by my boss on 31st Dec to fix a date rollover bug to 1st Jan at Client Co. and it was all my fault…)

After some more R&D, the next version of the software is ready. Customers may be slow to upgrade as it is not necessarily fully backwards compatible with what they already have - but you still have the release branch to support them until they are ready. When they upgrade, they get a completely new version from a new release branch.

So a release branch in some ways leads the mainline, because it is finding and patching bugs that feed into it. But on overall direction of the R&D, design of the system, features and so on, the release branches are downstream from the mainline project.

For me Elm is a goldilocks language, my favourite actually, I think overall the best programming language yet invented. So I would not want to fork it because I have no improvements to make to it as a language. But as people have noted before, its a bit of a walled garden. Thrust into the real world there is clearly an unresolved friction. That friction isn’t easy to fix, due to the way that the compiler and package system are tightly integrated, and the bottleneck on merging fixes back into it. That said, some of that friction has been very nicely fixed by third party tooling efforts along the way (thank you :pray:).

Now imagine that we had a release branch to handle the interface onto the real world. A place to fix issues, explore opportunities, support customers, and a place where those things could happen with less friction but a greater plurality of contributors.


Hi everyone!

Heartwarming to see so many people caring about the future of Elm. :slight_smile:

I think a fork is a wonderful idea. As unintuitive as it may seem, I don’t think of a fork as a threat to Elm at all. The more choices are available, the better a fit is available to the individual, which is only good! As I see it, only positive things can come of it:

a) Either the fork is a great success and everyone uses it instead. Maybe Elm learns from it or become obsolete. Regardless, there has been progress and people are happier!
b) Or the fork doesn’t work out, and we will all have a greater understanding of why things are the way they are. Also good!

If some people have a different vision for the language than Evan, then they should absolutely have the freedom to unfold and work towards that vision, just as Evan has the freedom to unfold and work towards his vision. This is the reason we have such a diverse programming language landscape in the first place: Elm was initially inspired by Haskell, but wanted to explore different priorities/goals and here we are! Maybe another great language will come from a critique of Elm. The communities of course remain closely related, just as Elm is close with Haskell and JavaScript- just more harmonious because more people can choose to work the way they want, towards the goals they wish.

As others have noted too, of course it is a lot of working to keep such a fork alive, but I think it’s worth a shot! There are obviously some very prolific people who wish for things to be run differently, so I trust in their passion to shepherd the project along. All that posting energy could be turned into programming! I know Evan supports a fork, too! Just make sure to call it something else, so there is no confusion about what people are choosing. Maybe “Ash” would be a cool name? Or some other three-letter tree name? Worst case scenario, it could function as a community-lead “unstable” release, where independents do the work of keeping it up to date / merging in changes, which would be a nice compromise: Evan doesn’t have to do extra work, and everyone else gets the changes they want.

Again, I recognize everyone is coming from good place, and I’m grateful for your engagement!


c) One or multiple forks live besides Elm which bring new ideas of what are good approaches and what to better avoid. A spec for Elm would also help to implement a diversity of compilers (like in C Land) in other languages, maybe so with different targets (Benefits of Elm Type System + TEA on Server)

Also I just came over this saying, which I kind of must agree with: “Wise languages designers start small and stay small.”


I did some analysis on Elm for a company early 2020 and ended up skeptical about applying this to a large Line of Business application.

Here is my first impression as I recall it:
The website had no recent updates or blog posts, the Search Result on google was broken (still is), the reddit was dead or dying, the discourse had some activity but mostly locked threads, the package manager has a lot of packages with few or no updates. Relative to React there are few public apps demonstrating its potential. I read some of the impressive, and some of the dismissive blog posts. I quickly dismissed the enterprise potential, and the project ended up with React.

I was intrigued enough about the promise of no runtime exceptions to continue learning the language and following the community on my spare time. After getting to know the language, its design goals, it packages philosophy, and its community better I now have a different view. It’s not a clear-cut decision in Elms favor, but it would not be dismissed before technical experimentation.

I think Elm and this community has something great brewing, but elm does not have adoption as its focus. And this lack of driving adoption is a blocker for companies looking to adopt. They default to the same safe choices as their peers, and elm no longer has that much of an perceived edge to other languages that the risk of being non-conforming is worth it.

Finally, this is not a personal or organizational critique. This is how I perceived the project from the outside when going in with NO prior knowledge to Elm. I write this as a data point to how this can be improved, as I have since become interested in the language and its possibilities.


I think that’s a great idea, and personally it’s a takeaway for me from this thread: “Let’s write a blogpost about ‘Elm at GWI’.”

Let’s “fight” the vocal negative minority and lack of outsiders’ feeling of uncertainty about whether Elm is dead, by being more vocal about our experiences writing Elm at work.

I feel we, as a community, are able to come up with great testimonials and experiences when prompted, but it might help to be proactive about it.

Actually one thing that popped into my head while writing this: what about having some logos and testimonial quotes on the Elm homepage? Ableton, MS, IBM are some that come to mind, … GWI :innocent:, Gizra, etc. etc.


I wonder who do you address with this ?

It was an idea aimed towards @evancz since he maintains the Elm webpage.

Love this energy! I’ll add the logos to the site (and fix the search result issue). If you have any testimonials at hand, let me know too! Thank you!


Tereza, I suppose you’ll need to ask the various representatives for permission, right? For example I’d love to get the GWI logo up there but I didn’t ask for nor get any permission yet internally within the company.

Oh yeah, of course :sweat_smile:Do you mind asking GWI? I’ll reach out to some others, too. If there are any other representatives in the thread, please let me know if you’d like the logo up!

(Edit: Feel free to send the logo + quote to - thank you!)


@terezka StructionSite wants to put up a logo!


Orange uses Elm in production :slight_smile: (I work on an Elm project for Orange)

Edit: I just asked for the permission to add the logo on the Elm website.

Edit2 : the link above is the link of the public portal of the company, not a link towards a website made using Elm. We use it for internal apps only by now.


I’ve asked the person in the company who I believe has the say in this; I’ll get back with a confirmation if I get it :slight_smile: Let us know if you also need some short testimonial quotes or something. Oh and I’m also writing that longer-form blogpost. :sweat_smile:


Arrival | The New Method - where @unsoundscapes just accepted a job



Job listings (from Elm Slack), may provide leads:

There are others further back, but I can’t see past the event horizon


Yay! Thank you! I’m curious if you have any quotes / blog posts I could link to as well?

1 Like

Great! A short testimonial would be wonderful, and a blog post even better! Thank you!

1 Like