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.