As a counterpoint to the inevitable "Is Elm dead?"[0] comments, how many other languages are still rock solid after 3+ years without a new version? Shouldn't we aspire towards using tools that are stable because they are complete?
What is the maintenance burden of the average React app? When I have written an Elm app, I feel confident that I could come back to it in a few years time with no issues.
To me, this stability is a testament to the language's thoughtful design and rejection of the constant churn of contemporary web development. At the risk of sounding like a Game of Thrones fan waiting for Winds of Winter, I look forward to the next version coming out with modest changes and bug fixes whenever it is ready.
That website justifies Elm's release cycle by saying that the language evolves slowly and that's a good thing, but you and they are conflating the bug fix release cycle with the feature release cycle.
I don't think people would be saying Elm is dead if there were regular bug fix patches coming out and we were on v0.19.21. The reason why people are declaring Elm dead isn't because new features haven't been added in two and a half years, it's because there hasn't been a bug fix update in two and a half years.
Sure, the language is stable in that it doesn't change, but stable can also mean bug-free, and Elm is certainly not stable enough to justify going that long without a single bug fix.
Yes, you are correct that bug fix release cycle and feature release cycle are different. If I felt that the majority of criticisms and comments were about bugs, I wouldn't have felt compelled to respond in this way. Perhaps I've misjudged that.
I will admit that the bug list is extremely disheartening. I have personally never come across them in the wild, but I don't doubt that when they do come up they are a horrible roadblock and the burgeoning set of community tools to work around this is telling.
There's also a difference between language features, and std library or browser API features.
I'm fine with Elm-the-language as it is, but I would definitely have preferred for a stdlib not to expose a function that are just a TODO.
I still use and enjoy the language, mostly because everything else in browserland is a pit of despair for me, but I could see some quality pull requests being merged once in a while.
There are probably people out there who think that a language should change more rapidly, but I think most people just take a quick glance at when the last release or commit was and judge that it's someone's hobby project that they've long abandoned.
Which is more or less true, given that Evan never let anyone else fully participate.
"Rock solid" in my day to day experience; obviously there are the issues reported on GitHub but I haven't come across these issues in real-world development. This bug is admittedly very poor, but it is straightforward to workaround.
I don't think the language is complete, but that we should aspire towards completeness over churn.
You thought you ate huh. This is “duck season” “rabbit season” type naysaying. It’s work aroundable if it ever comes up but I can tell you that it has not come up for me working in Elm.
People in the issue gave multiple real cases where it came up for them. If responses like yours are common in the Elm community when bugs are pointed out then that would explain a lot.
Ouch, not just the number, look at the type of issues. "Compiler error...", "compiler panic...", "elm publish hangs indefinitely..."
They never made it to 1.0, so it's not surprising, but major compiler bugs coupled with no chance of a patch (2.5 years since the last bug fix update) definitely suggests the language shouldn't be used in large projects.
Can you please list which of these compiler bugs are _major_?
There was a commonly encountered compiler bug in 0.19.0 (Map.! crash) and the 0.19.1 version was the result of fixing that. During 4 years of writing Elm full-time (close to 500kloc total) I have encountered only a "rank 2 typevar" typechecking bug _once_ and it was easy enough to work around. The Elm code that large projects need doesn't really trigger compiler bugs and crashes of the kind you'd see in the GitHub Issues.
If GCC has some bug reports open about crashes, but your code doesn't really trigger those in practice, would you call GCC unsuited for large projects?
If the last bug fix update on GCC were 2.5 years ago, I would absolutely steer clear! That I haven't run into them yet doesn't mean I won't, and the larger the project the more likely it'll be a problem at some point.
I agree that the list of issues is disheartening[0], although I would add that some part of this is due to the language designer's approach to issues (let them pile up organically and then sort through them).
Wow, that's remarkable. I can't fathom having the response of "why are you even doing this" instead of something more productive. It doesn't matter why they're doing it (and valid use cases are provided), negative numbers in a case statement should be supported regardless.
Edit: And finishing reading that thread now, Evan didn't even return once his question of "why" was answered. That's something else. I have no skin in this game, and people can run their projects as they see fit of course. But this behaviour doesn't make for a great community/ecosystem.
That's the appropriate response. You have to understand the problem to produce a solution. I don't read that as a negative response to the bug report. Just asking for more context.
What is the maintenance burden of the average React app? When I have written an Elm app, I feel confident that I could come back to it in a few years time with no issues.
To me, this stability is a testament to the language's thoughtful design and rejection of the constant churn of contemporary web development. At the risk of sounding like a Game of Thrones fan waiting for Winds of Winter, I look forward to the next version coming out with modest changes and bug fixes whenever it is ready.
[0]: https://iselmdead.info