Request: Elm 0.19.2: any update to help adoption to prove that Elm is not dead?

Just wanted to drop in and say thank you for asking the question. I don’t do that level of promotion, but I certainly love the language and see its benefits, and I can see where you are coming from. Even in talks with my team and other devs they hesitate with exactly the same sorts of things, so I can only imagine it for people who you are asking to invest $$ into it.

I think all the suggestions I have read so far are great. Not sure which is the right direction, but any momentum I think would be a welcome sign – if nothing just to show all the uninitiated out there that its fully supported.


This all resonates very well with me. My main selling point for getting anyone to jump into Elm was as a springboard to learning pure FP - which it is great for by the way. Other than that people just seem to shrug it off as more effort than its worth and fail to see the payoffs. That has been my, minimal I admit, experience at least.


After 5 or 6 years, and the clear abandon of the current version of Elm by the manager(s?), I finally gave up on Elm. My last attempt was to fork the compiler to remove the limitation for JavaScript in local applications, but I got runtime errors even though the compiler is written in Haskell. I found too hard to work with it mainly because:

  1. Lack of Haskell experience.
  2. IDE integration of Haskell with IntelliJ is very limited.
  3. There are a few uses of Map.! that break type safety, probably for performance, but debugging Haskell is hard.

Now, Typescript allows for strict types with good consistency, there are plenty of projects that make good use of typescript in the ecosystem, and the time where many developers wanted to learn Elm has past, so I am continuing my journey following a completely different path. Actually, I have more hope for roc than for Elm, because it seems to address important limitations of Elm.


Why did you want to remove this limitation?

I know it is a limitation of Elm, but it would be helpful to understand what you were actually trying to do that made you want to remove it.

1 Like

If you haven’t already tried it, ReScript React is nice.

Evan himself recommended using another language if you need confidence about the language:

I think having more flexibility in planning is a major competitive advantage for Elm, but obviously it is a trade off that does not work for everyone. If someone needs more certainty, I generally recommend looking into other languages to see if they have a balance that works better for their needs. For example, languages made by big corporations are generally “less risky” on things like this, but I think you see the fruits of that kind of process in the design decisions as well. Trade offs!

(from here, and that’s a small snippet of a large post; you should read the whole thing).

I put several months of nights/weekends learning Elm and eventually decided the complaints in this thread were dealbreakers to me (I still haven’t found a good alternative tbh), but, like it or not, this is how Elm works and it’s probably not going to change.

The thing that really helped me accept Elm’s “do the ‘right’ thing no matter the cost, no matter how long it takes, and Evan has to sign off or implement it” value was Bryan Cantrill’s PLATFORM AS A REFLECTION OF VALUES talk. It’s a great watch.

This reflection on Elm’s values makes me see Elm more as a hugely influential research language than a vendor-supported escape-hatched-if-you-need-it language I feel comfortable selling products on. This is just my personal opinion and I know a lot of people have their own opinion.

Any attempt to fork elm to provide such a production language should take a super careful look at Elm’s values to decide what tradeoffs should be made. I don’t believe it’s possible to add values like “contains escape hatches” (including through seemingly-unrelated things like an alternative package manager) without removing some level of commitment to Elm’s current “do the ‘right’ thing” value. To be clear, I personally think it would be great to have some experimentation in the space, but the tradeoffs are real and should be made intentionally.


For the people who are interested in just addressing low hanging fruit/open bugs, I still don’t think even this is happening. The discussion of batching and doing occasional updates seems like something that was happening a few years ago. Now, it just looks like a frozen repo that might get some amazing additions every few years but the routine maintenance of bugs in batching or whatever work pattern won’t happen.

1 Like

If you’ve not checked it out have a look at PureScript. It’s somewhere between Haskell and Elm and it has a really good JavaScript FFI (no need to hack in anything - you can just have a .js file named the same as a PureScript module that implements stuff you marked with foreign in the PureScript module - simple, efficient, a dream compared to Ports - also easy to add local/github packages outside the main repository).

For your trouble with the fork: you might have an easier time using VS code and GHCup - usually this works out of the box just as good as what you are used with Elm.

1 Like