"Stable" as in "doesn't crash in production" and "stable" as in "doesn't change backwards-incompatibly" are two almost entirely unrelated uses of the word. Most

"Stable" as in "doesn't crash in production" and "stable" as in "doesn't change backwards-incompatibly" are two almost entirely unrelated uses of the word. Most folks looking for a language prioritize the latter. There's no point in not having runtime ezceptions if your code stops compiling. I understand that removal of native modules was required for maintaining (some interpretation of) the promise of being crash-proof, and that it needs to be done before 1.0. My point is exactly that the language isn't at 1.0 yet. But more than that, my point is about the approach the developers take to the language, not about any specific decision. I'd still have the same comment about an Elm which lacked native modules from day 1, or an Elm where they figured out how to keep native modulea. Not running into breaking changes by luck is different from intentionally prioritizing stability and other people's use cases. It doesn't matter how many people are deploying Elm in production today—it's still a pre-1.0 language and maybe they shouldn't be deploying Elm in production.