The following is not a criticism of Evan’s choices on development path or of other aspects of the Elm community but rather a response to the argument voiced in this thread that the version number says Elm is just alpha so one should temper one’s expectations accordingly.
One might argue that the indicator of alpha v beta v whatever for a technology isn’t the version number but rather the point at which there start being conferences targeted at consumers of the technology rather than developers of the technology. Or at least that reflects how it is being promoted to the world even if the version numbering says that it is being treated differently from a development standpoint. One could infer from the version number choice that Elm is an alpha level, work in progress for which one should not expect bug fixes but if that is the desired inference then it probably needs stronger promotion to counter the image conveyed by other aspects of the Elm “marketing” —e.g., an Elm conference that opens with “Wow! I’m so impressed to see all of these people here for an alpha level technology.”
Right. If Elm is considered alpha-level or highly experimental software then that needs to be communicated very clearly in any marketing efforts as well as in the official docs.
There’s no problem with a project remaining in alpha status for an extended period of time, people just need to know about it so they can make informed decisions in their work.
There are two sides of this I think. One the one hand, yes Elm is an alpha (0.18) in the sense that retrocompatibility is explicitely not taken into account at each new version. This is probably not explicit enough. But on the other hand, it is a very stable alpha since breaking releases happen roughly every year. Plus recently, transitions have been done semi-automatically with the help of tooling.
In any way I think that a team thinking about adopting a relatively new/small language like Elm should first talk to people already on board, either physically at meetups or with the community online (discourse, slack, reddit). And any elm dev with more than 1 release cycle experience could answer these questions. This with the added benefit of having more specific answers, drawbacks, pitfalls and resources references.