Having followed the language for quite a while, including some of the controversies, I think there's two things you need to be mindful of:

1. The language version starts with 0, i.e. it is being clearly communicated that there is no guarantee of stability

2. The language development is being run by an opinionated BDFL who likes to take his time to think through new features. There's more of novel, well-thought-out ways of doing things, but less support for "I need this for my production use case now"

Neither of those points is inherently bad, but if you plan to adopt Elm in your product or codebase be prepared to rely only on the feature set you get from current version. Expect breaking changes in the future when new version drops.

There's lot to like about the language and it can be a good introduction to functional programming if you are not yet familiar. IMO it is definitely worth spending time on to improve your skillset and to gain new perspectives on programming.

I don't want to claim I am an expert on different programming languages. I really wanted to supplant my JS use-cases with Elm, but the ecosystem is too closed for proper collaboration.

The biggest restriction on adoption is that the language is a gatekeeped brainchild of limited number of devs. They are inclined to build the language around use cases they want, instead of what people who use their language want.

They have effectively closed the gate to having other talented FOSS devs supercharge this language with features that allow it to run circles around other languages currently in production systems (mainly JS)

It's their right to do so if they wish, but it means that I can't consider this language in any serious capacity. It means the language lacks flexibility and reactivity to changing circumstances, and while it describes having a default library without extendible ecosystems as a "feature, not a bug", they've essentially put a ceiling on what is practical with their language in doing so.

I really wanted to like this language, but the more I learned about it, the more I felt disappointed over what could have been.

> if you plan to adopt Elm in your product or codebase be prepared to rely only on the feature set you get from current version. Expect breaking changes in the future when new version drops.

Conversely, though, the language owners also don't get to have it both ways: if they aren't interested in committing to stability and (some measure of) implementing these production use cases, then they should not act, or promote it, as if it is a production-ready project.

That’s quite a strong indictment of most of the JavaScript community/ecosystem.

? I didn't say anything about JavaScript.

I tried to use wit. Evidently I failed.

I see, sorry I missed it.

If anything, the insanity just got worse: https://github.com/elm/compiler/issues/1773#issuecomment-418...

There's an open bug re: negative literals, and accusations of bad faith towards the reporter.

Evan is a very difficult person to deal with.

I'm keeping my anonymity on this HN account, but I've clashed with him before on a Github issue on what should have been a trivial routine update.

I feel like this exchange is this skit writ small...https://www.youtube.com/watch?v=sngRrkQayDA. Evan meant a congenial "why are you doing this" as in like..honestly why do they match negative literals? Everyone took it as an accusatory statement that implied "you moron, why would you do such a thing?" which I at first took it that way too so I can totally understand! But on reflection I think he wouldn't react that way and I believe he was just misinterpreted. And by fake examples he meant contrived examples. He wasn't accusing them of acting in bad faith I don't think.

I didn’t get that sense in reading this. Evan’s concerns seem to be:

1. do other languages allow this? i.e. have other languages prioritized this for development?

2. what are practical situations where it has come up?

Which seem like pretty straightforward questions to ask if you’re trying to prioritize this issue. I get that Evan was a bit curt in asking (2), but I don’t see an accusation of bad faith…

If your language has a pattern grammar where one subset of numeric literals is valid as a pattern and another isn't, your parser is simply broken. There's no question of prioritizing this or "real-world" use cases. It's a basic issue of does this work like any reasonable programmer would expect. The response there is nothing more than "you're holding it wrong"[0].

[0]:https://www.urbandictionary.com/define.php?term=You%27re%20H...

The question is not whether it’s broken or a bad experience. Clearly it is. But software engineers KS stuff like that all the time. The question is: is the cost-benefit worth spending extremely limited resources to address? It is not hateful or dismissive to ask that question.

I’m a bit confused by your interpretation of the dialogue in that thread, especially given that — as I understand it — you are an individual with perhaps a stronger grasp of FP and PLT than anyone else reading this page. I think you can recognise that the design goal and the constraints described in the original comment are nebulous since the most trivial implementation without a case match would have been obviously correct. I don’t know where such an uncharitable interpretation of Evan’s question comes from.

Could you help me understand? What am I missing here?

My personal opinion is that it is a great introduction to functional programming in a front end environment, but the issues that have led to that drama are a huge turn off for production.

There are lots of great typed functional programming tools for the front end with varying levels of type features. All of them offer interoperation with JavaScript in various forms. I am sure there are more that I have not heard of.

Fable (F#)

GHCJS

js_of_ocaml

Purescript

Rescript (formerly ReasonML)

TypeScript

It's a pity, because it may be one of the best ways to get started the pure-FP while also getting some really cool "visible" things built (because it targets the browser).

I'd say forget about the drama and just build something with it. You will probably never notice anything from that drama while learning.

How much does any drama in any language you use actually effect you?

Wouldn't base my choice on that at all. Learn it to learn something new and expand your horizon if you want to. Or learn it if you think it's valuable to use in its current state (it is). What some people quab about is irrelevant.

When you choose to invest time into something that might end after a flamewar, it grinds your motivation a bit. It's not life critical, but it's in your mind.

There is drama everywhere: on the Linux kernel, on Github, Python, Systemd,... People are getting annoyed all the time

There is different levels of drama and amount of contributors plus funding though.

Do I fear that the Linux kernel, which is used by pretty much all Fortune 500 companies and has a huge amount of paid devs, will die in a huge flamewar? No!

The same doesn't hold true for someones hobby project though.

And I am well aware, that Linux was a hobby project once, doesn't change a thing about current state though.

True, but these are already established tools. So it evens out.