[antouank]

Why is the pace of releases an important metric for using a programming language?

Focus on code quality, and maintenance simplicity.

If anything, being able to use the same version for x years and having it be consistently better than any JS library/framework I used, means that the work done is of high quality.

Maybe you should watch Evan's talks from various Elm conferences ( search on youtube, for example https://www.youtube.com/watch?v=uGlzRt-FYto ) He addresses that concern that some people have, and why it has the pace it has.

As I understand it, it's better to do things right and take as long as it needs, rather than hurry and ship fancy things just to ship them.

Elm is perfectly production ready as is, and beats any JS stack for me. Both in code quality and maintenance cost.

[mebassett]

my startup uses elm in production.

There are plenty bugs with the current featureset in the elm compiler. The next version is going to break many things. This puts users of the platform in an awkward position where they have to put up with bugs for an indefinite amount of time, and when a release does come it is going to break a lot of code.

this isn't something I'd expect in a "production ready" language.

frequent patch releases would be ideal. Though the version scheme of elm does not respect semantic versions. Which introduces another problem - unless you're "in the know" about elm, its difficult to even tell that the new release is going to break your code.

[amarshall]

Regardless of whether it claims to adhere to SemVer, Elm hasn’t had a 1.0.0 release yet, and, as such, the following SemVer clause applies:

> Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

That said, it’s reasonable to think that Elm should have had a 1.0.0 release by now.

[mebassett]

Apologies, I should have been more clear. I don’t know if elm /claims/ to adhere or not. I only know that in practice it doesn’t.

But thank you, that is an important point; elm’s own version numbers suggest it isn’t ready for production. Use at your own peril.

[aeorgnoieang]

If releases are the primary means by which bug fixes are distributed then a slow release pace means a slow pace at which bugs are fixed.

Otherwise, I too enjoy the stability of using working tools that don't necessitate a lot of fast-paced changes.

[antouank]

Agreed.

But the main thing to check first is : are there many bugs? Struggling to find any. On the other hand in js...

I suppose it's more of a perception thing. We are used in js-based projects to have a lot of bugs as a given, so plenty of updates is a good thing.

[xtian]

Yes, there are bugs in Elm. Anyone who's worked on a production app will have run into issues with the compiler and/or first-party libraries, all of which are maintained by one person (as well as all of the official documentation, the package repo, CLI tooling, etc, etc). I'm a big fan of Elm in general, but I couldn't recommend it to someone unequivocally.

[antouank]

No one claimed it's perfect and bug free. But let's compare it to any js stack with thousands of libraries in the project's `node_modules` directory, written by thousands different contributors. That's what Elm is replacing.

[xtian]

You did claim that you were “struggling to find any” bugs in Elm. There are definitely a lot of bugs in the JS ecosystem, but one should also compare the avenues for remediating bugs in that ecosystem versus Elm (easier to fork/patch buggy code, more frequent bugfixes, more alternatives, etc).

[megaman22]

The shiny is wearing off... But I agree, ideally, a tool isn't going to need a new version released every six weeks, if it is high quality and feature complete.

But expectations are completely upside down in the web development world, so that rather than things becoming mature and stable, they are seen as stale and abandoned.

[nine_k]

If there are no important outstanding bugs, are there any sorely missing features?

Does anything rot in the codebase as the JS in browsers (the target compilation platform) is constantly updated?

[xtian]

There are both long outstanding bugs and sorely missing features in the currently released version.

[brabel]

You keep claiming that without providing any links. Care to post links to bugs/features you miss?

[xtian]

My best reference for links would be the Slack logs from the job where I was using Elm full-time, but I'm not at that job anymore. If you're interested I would recommend trawling the issue trackers for the elm and elm-lang GitHub orgs as well as checking out the Elm subreddit and Discourse. Threads which discuss the limitations of the way the project currently operates or native JS workarounds to issues are often locked or moderated on those forums, however.

Off the top of my head, a couple of the compiler issues we worked around were case statements on a tuple causing non-linear increases in compilation time and the compiler hanging indefinitely when trying to infer certain types from our GraphQL library (which is an awesome lib; check out dillonkearns/graphqelm if you want to see Elm at its most useful). We also ran into a case rendering live-updating graphs where Elm would stack overflow after a certain number of internal messages.

As far as features, only a small portion of browser functionality is available in Elm and many of the integrations that do exist are not as complete as you might expect coming from another ecosystem. For instance the only way to do SPA navigation is to add explicit click event bindings and message handlers for every link. The port-based JS interop functionality is great for many use-cases, but we found it pretty awkward for others. A couple of these cases were blob file uploads and calling + reacting to `window.confirm`. The JS code additions to enable these features within Elm are very simple, but third-party libs can't include JS and it's unlikely to get a PR acknowledged much less accepted to anything first-party, so people end up hacking together their own fixes for lots of little issues in isolation. And the ability to do JS workarounds is apparently being curtailed even further in the upcoming release.

Some of the issues we had will be fixed with the release of 0.19 (namely, the compilation time issues and the SPA nav), but those fixes come along with a slew of breaking changes and after nearly two years since the last release. Information about the contents and development of that version has only started coming out in a meaningful way in the last couple of months. Up until that point it was basically rumor and hearsay, and we spent a lot of time wondering how we would justify to the rest of the company having made a big commitment to a seemingly abandoned language.

Overall I have fairly nuanced feelings about Elm which are difficult to communicate in this context. It's one of my favorite languages and I often feel very productive using it. I think it's an great achievement as a piece of technology and I agree with almost all of the design tradeoffs it makes. But I think if the project is meant to be used in serious contexts — a question which I should not even have to wonder about — then it has grown beyond the scope that one person can manage on their own. Evan has actively resisted enlisting and empowering the community to help realize his vision for the project and solve their own problems, and I think there is plenty of evidence that that is a worthwhile and feasible goal. Elixir is my go-to example for a project that does a great job at this and has benefited significantly from it.