Elm's management has left me with the impression of a really smart, well-intentioned hellscape.
Searching for almost any problem I encountered, I'd invariably find two or three Github issues that were exact matches. These were, with impressive consistency, closed about two hours later with a link to some "Meta-Issue for Improvements to our Float handling" or something like it.
That issue, in turn, would usually be closed by some check-in that had nothing to do with my original problem.
Other times, the link to the "Meta-Issue" would get you a 404 because the compiler repository was merged with the documentation repository, and both were subsequently moved to the Elm-Lang project, then renamed to "elmlang". Oh, and feature requests are now part of project elm-future....
Elm is seriously nice to use. But it'd be twice as good if they lost all accounts that have admin privileges for the Github tickets.
A major problem that I see with Elm is that it seems, from the outside, to have a bus factor of 1. Looking at the commits for the compiler and other core libraries you only see one name over and over again: Evans.
Evan has created a very streamlined and pleasurable frontend experience, but IMO his tight control of it will lead to it's demise for a variety of reasons:
1. Something happens to Evan (Hopefully not)
2. Evan decides the foundations need to be replaced (For example if he moves away from the 'Elm Architecture', it will cause a great rewrite and when great rewrites happen developers evaluate other options. e.g. Angular 1 -> Angular 2.)
3. Evan gets burnt out
I'm okay with a BDFL, but not a sole maintainer. I think he needs to raise up others to maintain it for it's long-term health.
Note: Creatively I can understand his desire to control the experience. It also make it feel very unique as a programming language where you are guided in a very narrow path in development, but I believe like most creative works they get better with remixing. When the idea is allowed to be evolved, played with, broken and pushed. Yes, most of those changes will be bad but how else can we know besides trying? Those extensions of Elm's ideas are sadly currently happening outside of the Elm ecosystem because of Evans control, which I think will also lead to it's slow demise.
I think Evan is too protective of the language to let anybody else maintain it right now, the first step would be for him to realize that he should give it up just a bit.
It's a fascinating experiment. A language that's actually a single developer's walled garden, where they make all the decisions, write all the code, and personally vet every library. (There must be other languages where the language team devs hvae to individually approve every package before allowing it to be added to the package manager, but I certainly haven't run across it before!)
It's quite enjoyable to watch, but obviously it's not scalable or sustainable in the general case.
> Elm's management has left me with the impression of a really smart, well-intentioned hellscape.
That seems fair, yes.
My personal view is that there's about a 90% chance the project will collapse under its own weight before it ever hits a release and becomes a normal project, but there's a 10% chance it'll (one day) migrate into a real language (with a real governance model, an actual team working on it, bugfixes being shipped, etc.).
You are wrong. Anyone can publish a package for Elm - without approval.
What you can’t publish is a package with JavaScript in it. And, if you understand Elm, this makes sense.
Elm has no runtime errors - which means any JS has to be perfectly designed. Elm is not to be bound to just a JavaScript platform. Elm has ports for interior.
As for bug fixes - there appear to be some cases where there are bugs, but I have never come across any. The langauge just works.
The slow pace of releases is a business adavatage - we don’t need to be upgrading every N months.
The last upgrade had tools to automate almost the entire process.
Anyway. Would you wager that Elm will fail? I will put up $1000 to your $9000.
It's an interesting topic. We use Elm at work, but I don't work with frontend development so I don't have a lot of hands-on experience with it.
From following a few of those Reddit thread (the linked one and also [1] about a week ago) it seems like there is some growing concern about the BDFL-type development model that Elm is using.
From a casual user's perspective and as someone with a background in Haskell development, Elm appears sort of unmaintained (PRs being ignored, no new releases/updates/anything in a long time) and unfinished (there are many "Haskell-features" that Elm has no equivalent to (yet), which leads to developers writing a lot of repeating code especially in areas such as JSON (de|en)coding).
None of our work Elm code bases are particularly large (yet), and the developer doing the bulk of our frontend work is also a Haskell person by heart. We'll be staking out PureScript as an alternative, though we'd probably like to keep the idea of the "Elm architecture" alive there, too.
It seems as if the Elm team is currently doing what SPJ once referred to as "avoid success at all costs" in order to ensure that they really nail the features they care about, but they're doing it after already having started a hype- and marketing wave several years prior, which is leaving people stranded in uncertain territory.
I have been looking at Elm as an example of how to engineer the ergonomics of a functional language, and how far one can come with a focus on simplicity and consistency. Unfortunately, it also looks like it is becoming an example of the problems of going too far. I don't actually mind Elm's weaknesses as discussed in the Elm Is Wrong essay[0] - these look like an ordinary technical trade-off - but the social consequences of how Elm is managed seem a little
more subtle.
[0]: http://reasonablypolymorphic.com/blog/elm-is-wrong
It seems like this is the sort of thing that causes projects to fork. For example, egcs from gcc and IO.is versus node.js. In those cases it apparently worked out well (from an outsider's point of view), but I'm sure everyone would prefer to avoid the drama.
I really want to love elm. But i dont want to use it for any major project mainly due to its development model. I ca understand the next version taking time. But having no transparency about whats going on and when will it drop doesn't gives me confidence about the project. There are just too many issues and untouched PRs in there.
Rust is a language, and it can bind to C libraries. Java can import DLLs and shared libraries. Haskell can do this too. All popular languages that can run on a server can spawn a process and communicate via file descriptors.
Useful languages can interop with other languages.
Well, Elm does have interop with Javascript through ports. The mechanism is asynchronous which creates an explicit crash boundary at the expense of a mechanism that is more roundabout than just calling `foo x` when you want to wrap a Javascript library's `lib.foo(x)`.
Elm 0.18 and below (not sure what 0.19 is doing, it's not released) has synchronous interop through native modules, but those have been discouraged and documented as "do not use, will change in the future" since the beginning. And you can't easily publish them to the package repository.
To say Elm doesn't interop with Javascript is just wrong.
You may disagree with Elm's stance on its synchronous interop, but you're just disagreeing with trade-offs. Like all trade-offs, just because someone chose different ones than you doesn't mean they were oblivious to them.
I'm actually in full agreement that there are many ways to accomplish interop, with a variety of tradeoffs. It is precisely for that reason that I disagree that the statement
'One thing to understand is Evan wants Elm to be a language and not bound to JavaScript.'
is a good explanation (or a 'sound motivation') for the current design decision. Thank you for expanding on the goals of the current design. People less familiar with Elm, such as myself, have learned something about Elm's capabilities and strategies for dealing with interop.
Alternately, it exposes the creator of Elm as someone who should have thought harder about naming, and not chosen the name of a very well known piece of software that predates theirs by a few decades.
I'm not sure it does. I think people use Elm to signal to fellow oldtimers that they were indeed around when people used that email client, DAE remember?
I'm not even sure I've ever seen a HN submission about the email client. And they're in such different niches that you, precisely, have to write a comment without clicking in to the article. At which point, what value are you contributing to the discussion?
You're basically suggesting that choosing a different name would increase the odds of someone being more relevant when writing a comment based on a submission title. Not very compelling. These comments just get downvoted where they belong.
One of the worst aspects of HN are top-voted arguments that have nothing to do with the subject matter of the article. We don't need more of those.
Like others have mentioned, it seems that elm has done a great job of promoting itself, but lacks the structure to make big changes.
It screams of needing some sort of governance and RFC process ( edit: seems that there is an RFC process [1]) so that all parties could make their case.
The Angular 1 -> 2 transition should be a lesson to most that if you leave your users hanging, they'll go find another ecosystem.
Definitely agree. I wouldn't even call the angular thing a transition, since it basically threw everything out. It should've really been called something else.
There's also big examples like Perl 6 and Python 3.
IMO, you can make breaking changes as long as it's done gradually and you provide a clear migration path. After experiencing React's strategy [0] for a few years, I'd say it's become my gold standard for how breaking changes should be made.
The React team seems that they put a lot of forethought into keeping the API and core stable. I was super impressed at the core rewrite that integrated the fiber architecture. The console warnings are a nice nod to good developer ergonomics.
The upgrade from Elm 0.17 to 0.18 was almost 100% automated. I thought it was going to be painful - but, thanks to the type system, wasn’t. Nothing like Angular.
If I recall correctly, Elm grew out of Mr Czaplicki's PhD thesis or project. It seems that he still considers it _his_ project, which is fine for him and his employer but it does it make it hard for those not close to him to see where the language is going and get support.
In a perfect world (according to me), Elm would have 5-10 people in its core team, with at least a few of those tasked with triaging issues and PRs. That wouldn't mean "giving up" control of the language and its future.
> Elm would have 5-10 people in its core team, with at least a few of those tasked with triaging issues and PRs
That would be amazing, but I see this being very similar to Node in its infancy. It took a fork (io.js), and a lot of strong opinions to get Joyent to relinquish its grip on the ecosystem.
I think what the developers who forked Node into io.js showed was competency and care with regards to progress. I'm not sure that could ever happen in the elm ecosystem due to it being somewhat small and niche.
If Node was in its infancy when the io.js fork happened, then Elm is downright fetal. I don't think you can compare them.
It seems to me that the extreme BDFL governance of Elm is also its strong point at the expense of being then limited to that bandwidth, it's weak point.
Unfortunately, delegating work does not come for free and a great deal of energy will be burned in people management. Unless you're clairvoyant, it can't be said whether that would be any better for Elm or mire it in an even thicker mud.
Elm has a lot of unknowns that someone has to sit down and make decisions about because it wants to generalize over environments beyond browser-side Javascript. I think that sits at the root of why you can't just delegate out core contributor access.
But trying to do that generalization in the first place is also why Elm has some really interesting potential in the long run than just another SPA abstraction.
As I've participated in Elm's growth over the years, more and more I feel for the React devs who are pulled in many different directions by impassioned voices on every side. People have really strong feelings about how open source software authors should spend their time.
I read the GitHub issues linked in the OP of that thread. Two are feature requests, and one is a bugfix for a behind-the-scenes problem which apparently has no noticeable symptoms. I understand OP's frustration that these haven't been merged or closed; nobody wants to do workarounds, and everybody wants feedback when they post on GitHub. I'm also personally sympathetic to the idea that Elm core libraries should have more frequent minor releases, which I agree with.
The thing is, I also understand that when open source authors prioritize engaging on GitHub, that implicitly means not prioritizing other things. People think "how hard can it be to write one sentence of feedback as to whether this will get merged?" but that's not how GitHub works socially.
An under-appreciated reality of OSS is that maintainers have two options: engage in a back-and-forth with issue posters until the issue is resolved to the poster's satisfaction, or brace for complaints that you're unresponsive. If authors conclude other priorities are higher than seeing that issue through to its eventual conclusion - however much time that may take up - it's understandable why they wouldn't even begin that conversation in the first place.
(Naturally, those who prioritize responding on GitHub are subject to complaints that ambitious long-term projects are taking forever and perhaps deserve to be labeled vaporware.)
If you have a BDFL, some will say things are moving too slowly because the BDFL doesn't have enough bandwidth. If you have a committee instead, some will say things are moving too slowly because there's too much bureaucracy. Trade flexibility for guarantees? Some will call that stifling. Trade guarantees for flexibility? Some will call that dangerous.
We programmers have every possible combination of preferences, and those whose preferences already align with a given project tend not to bother posting about it online - because they're off happily using the thing that's worked well for them. I think this is why I've found contributing to open source consistently rewarding but frequently exhausting.
A lot of this boils down to figuring out a delegation model that works for Elm.
Does the BDFL of the language really also need to be the only person maintaining core libraries? The only person maintaining project communications?
In this particular case it feels like the Elm team is afraid of "losing control" over the language.
That's often in direct contradiction with the project becoming more popular, so for a while maintainers need to choose between advocating the thing they're building and advancing it in the way Elm is currently being advanced.
Once things like [1] start appearing in the codebase you're basically asking people to fork your project and what happens after that is unknowable ...
I've been using Elm for years now and it's always been openly admitted that core abstractions are still being decided. You can just look at the change log between versions (which are all sub-1.0) to see that.
You have to be okay with that to use it in production. Else you would have used something more stable instead of decided to gamble.
I think Elm is still too early to bike-shed over governance model. And people seem to think Elm is a lot farther along than it really is. Else they wouldn't have the expectations that they do. Or they wouldn't go "I don't have these issues with React."
I think the social issues Elm has are just what it's going to take if Elm wants to arrive at something more compelling that just another language. If there's a continuum with BDFL on one side and design-by-committee on the other, then you're going to have issues no matter where you move the needle.
The upside of the bus-factor-of-1 approach is that you have a visionary in the Hickey hammock. And the unavoidable downside is that you have to deal with the bandwidth of one person which describes a lot of the social issues.
I think that anyone who is uncool with that reality chose the wrong language. And a lot of the criticism that results from that, like this: https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing..., starts to reek of the hot air of entitlement, to use Rich Hickey's words.
> A lot of this boils down to figuring out a delegation model that works for Elm.
I agree. This is harder than people think; we've tried some delegation models in the past that didn't go well, and we reverted back to the way things were previously.
We're still trying new approaches. The next release will have a core module (Array) written and maintained by a community member (Robin H), and I predict the debugger will be the next core project to fully transition ownership from Evan to a community member.
If these go well, they can be models for future delegation to community members!
> you're basically asking people to fork your project and what happens after that is unknowable
It's pretty predictable though - forks basically always fizzle out unless it's major contributors splitting off (as was the case with io.js), and there aren't factions like that among Elm's most prolific contributors.
Turns out it's a lot of work to make something people really want to use!
Dumb question but I recently was looking at Elm and ReasonML (by Facebook) and don't really know the difference... they seem to try to achieve the same thing no?
(Disclaimer: I only have experience with Elm, not ReasonML)
Their goals might align quite a lot (functional programming for the browser; compiling to JS), but Elm seems to me more "pure" than ReasonML, and places extra emphasis on correctness ("no runtime errors").
For example, ReasonML allows you to put JS code inside its source [1]. Which might be great if you want that escape hatch, but might mean that runtime errors are common when working with ReasonML. Elm trades a bit of convenience for the enforced reliability.
I'm on the side of why don't you just let Evan do his thing? Maybe a big part of why Elm is kind of really awesome already is because it's being developed differently. Just let a cool language develop differently this time! It might turn out to be great.
And for people who supposedly have so many lines of an alpha language in production, why are you confused about how Elm is being developed? I'm not even using it, but just an interested follower, and it's been pretty clearly explained how he plans on developing it. A couple highly visible threads here and there (some in quite poor taste too) and you are bound to have been given solid, well thoughout references to why Elm is developed this way. I've seen tons of disclaimers that you are using an alpha language in production at risk. No one was misled.
I'm all for letting people do their thing and try different approaches.
But honestly to me it seems the elm community wants to have their cake and eat it too. Of course that is not a trait unique to them.
As somebody not involved with elm I mostly get to hear about the language from the marketing side. And it does get advocated as production ready (or as least as production ready as anthingthing else in the js world, to paraphrase some talk) and the alpha status, it being still a young language and use in production at own risk only ever seems to really come up when there is some push back.
E.g. I can't see any mention of being "alpha" or warnings on the elm website, besides the version number indicating it. Instead it says things like "elm guarantees no run time exceptions in practice", but when I go to Github issues, I find several of them, including intentional and accepted ones.
It seems to be a neat language, but for now I'll just stay away from it and let them do their thing.
The License looks like a modified MIT, with 2 extra clauses (the binary must produce the copyright, and the author's name can't be used to promote anything else).
Reading through the thread, others don't want to fork because it would split the community of an early language. They don't want to take Elm in a different direction, just bugfixes.
I think that the main problem with Elm is that Evan wants to design the perfect system.
This is of course a laudable goal but I think that clashes with the complexity of the real world.
A consequence of this is that if you want to do something Evan spent time designing a solution for you're going to have an awesome experience, he is a great designer, but on the other hand as soon as you try to do something different you're out of luck.
This has the nice effect that what's there is really nice but there is no middle ground and you either get something that is well deisigned and extremely polished or nothing at all.
I liken it more to Evan investing "hammock time" (https://www.youtube.com/watch?v=f84n5oFoZBc) into Elm because he has loftier goals than just another SPA abstraction. Which is a bit different than perfection.
There are just too many cats that can be released from the bag that would be too hard to reverse once out in the ecosystem. Classic example would be allowing native modules into http://package.elm-lang.org/.
This puts you in a position of treading cautiously with the long-term in mind while your users may clamor for quick fixes that jeopardize the overall strategy.
So I agree with you. This results in the "something good vs nothing at all" release cycle that you point out, but I think its a more accurate explanation of why that is.
The rest of the issues seem to be related to his limited bandwidth. And I suspect Elm is tied so much to his bandwidth because such fundamental design is still being decided.
> I think that the main problem with Elm is that Evan wants to design the perfect system.
This. For the good and for the bad Elm's creator seems to be a perfectionist and every perfectionist is a control freak (I'm a recovering one). If you read the Elm newsgroup you'll see that he even controls the website design. By the other hand - if we wait some years - we have a good chance of getting a great language.
I love Elm. We use it in production, though we're not primarily a "web" company and it's used for admin UIs and simple SPAs.
Nothing in Javascript / HTML is very stable--I've hitched my wagon to so many stars that burned out. Everything from XSLT to JQuery to Bootstrap. So the fact that probably, something will replace Elm doesn't bother me.
It works now, it's stable, and it hides most of the crap from me so I can just code. It helps that I've been a "Functional Programmer" since 1980 when I first learned LISP, and that our core products are done in Erlang and F#.
I've been using Elm on and off for projects for the last couple of years. I find that most of the complaints are just discomfort at how Elm isn't developed the way that many other projects are. It gets in people's heads that they have to trust in Evan's judgment when they don't see a new release popping out every quarter.
I actually like the pace of releases and lack of frequent breaking changes. I'll put some projects aside for 6 months here and there, then come back to them when I have time. Most rapidly-evolving frameworks require you to update all your libraries and fix a ton of breaking changes when you don't touch them for a few months (I'm looking at you, Swift). After I spend all that maintenance time, I often wonder at the value of those changes in the first place. Were they really changes that buy me new flexibility with the language? Or were things just renamed and shuffled around with syntax changes made for no great reason?
When talking to people about using Elm, I discourage them from using it if they're the kind to obsess over the release cycle of a framework that's stable today and that allows them to get quality work done.
This is a good point, but on the other hand it's sad too see that 0.18 has been abandoned and there are pull request that would fix bugs being ignored.
I don't mind that 0.19 is taking long time to be released, what bothers me is that there are no bugfix release for 0.18
I'm not using elm but i do like slower release cycles. For example some years ago I wanted to give node.js a shot for some backend stuff for a side project. But every couple of days when I wanted to work on it I had to spent half an hour fixing the build, so I gave up.
But at least in the linked discussion, the pace of releases doesn't seem to be an issue, but the lack of communication about what is happening. No clarity whether native extensions will work, if pull requests opened years ago will be merged or at least responded to, whether there will be bug fix releases, etc.
To me it seems, that elm community uses this straw man making it about people just wanting faster release cycles in response to valid criticisms in every unpleasant reddit thread I've have ever seen. Not pointing at you here, since you are not mentioning specific cases.
You like having a fix open in a PR for 2 years and then learning that your work around for the fact that fixes don't get merged or released is going to be also blocked? Because that seems to be what is happening to the person who opened this reddit thread.
62 comments
[ 1.2 ms ] story [ 141 ms ] threadSearching for almost any problem I encountered, I'd invariably find two or three Github issues that were exact matches. These were, with impressive consistency, closed about two hours later with a link to some "Meta-Issue for Improvements to our Float handling" or something like it.
That issue, in turn, would usually be closed by some check-in that had nothing to do with my original problem.
Other times, the link to the "Meta-Issue" would get you a 404 because the compiler repository was merged with the documentation repository, and both were subsequently moved to the Elm-Lang project, then renamed to "elmlang". Oh, and feature requests are now part of project elm-future....
Elm is seriously nice to use. But it'd be twice as good if they lost all accounts that have admin privileges for the Github tickets.
Evan has created a very streamlined and pleasurable frontend experience, but IMO his tight control of it will lead to it's demise for a variety of reasons:
1. Something happens to Evan (Hopefully not)
2. Evan decides the foundations need to be replaced (For example if he moves away from the 'Elm Architecture', it will cause a great rewrite and when great rewrites happen developers evaluate other options. e.g. Angular 1 -> Angular 2.)
3. Evan gets burnt out
I'm okay with a BDFL, but not a sole maintainer. I think he needs to raise up others to maintain it for it's long-term health.
Note: Creatively I can understand his desire to control the experience. It also make it feel very unique as a programming language where you are guided in a very narrow path in development, but I believe like most creative works they get better with remixing. When the idea is allowed to be evolved, played with, broken and pushed. Yes, most of those changes will be bad but how else can we know besides trying? Those extensions of Elm's ideas are sadly currently happening outside of the Elm ecosystem because of Evans control, which I think will also lead to it's slow demise.
It's quite enjoyable to watch, but obviously it's not scalable or sustainable in the general case.
> Elm's management has left me with the impression of a really smart, well-intentioned hellscape.
That seems fair, yes.
My personal view is that there's about a 90% chance the project will collapse under its own weight before it ever hits a release and becomes a normal project, but there's a 10% chance it'll (one day) migrate into a real language (with a real governance model, an actual team working on it, bugfixes being shipped, etc.).
What you can’t publish is a package with JavaScript in it. And, if you understand Elm, this makes sense.
Elm has no runtime errors - which means any JS has to be perfectly designed. Elm is not to be bound to just a JavaScript platform. Elm has ports for interior.
As for bug fixes - there appear to be some cases where there are bugs, but I have never come across any. The langauge just works.
The slow pace of releases is a business adavatage - we don’t need to be upgrading every N months.
The last upgrade had tools to automate almost the entire process.
Anyway. Would you wager that Elm will fail? I will put up $1000 to your $9000.
From following a few of those Reddit thread (the linked one and also [1] about a week ago) it seems like there is some growing concern about the BDFL-type development model that Elm is using.
From a casual user's perspective and as someone with a background in Haskell development, Elm appears sort of unmaintained (PRs being ignored, no new releases/updates/anything in a long time) and unfinished (there are many "Haskell-features" that Elm has no equivalent to (yet), which leads to developers writing a lot of repeating code especially in areas such as JSON (de|en)coding).
None of our work Elm code bases are particularly large (yet), and the developer doing the bulk of our frontend work is also a Haskell person by heart. We'll be staking out PureScript as an alternative, though we'd probably like to keep the idea of the "Elm architecture" alive there, too.
It seems as if the Elm team is currently doing what SPJ once referred to as "avoid success at all costs" in order to ensure that they really nail the features they care about, but they're doing it after already having started a hype- and marketing wave several years prior, which is leaving people stranded in uncertain territory.
We'll see how it works out ...
[1]: https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing...
In the meantime 0.18 has been a very productive language.
One thing to understand is Evan wants Elm to be a language and not bound to JavaScript. This is the sound motivation behind blocking native packages.
Useful languages can interop with other languages.
Elm 0.18 and below (not sure what 0.19 is doing, it's not released) has synchronous interop through native modules, but those have been discouraged and documented as "do not use, will change in the future" since the beginning. And you can't easily publish them to the package repository.
To say Elm doesn't interop with Javascript is just wrong.
You may disagree with Elm's stance on its synchronous interop, but you're just disagreeing with trade-offs. Like all trade-offs, just because someone chose different ones than you doesn't mean they were oblivious to them.
'One thing to understand is Evan wants Elm to be a language and not bound to JavaScript.'
is a good explanation (or a 'sound motivation') for the current design decision. Thank you for expanding on the goals of the current design. People less familiar with Elm, such as myself, have learned something about Elm's capabilities and strategies for dealing with interop.
callJS :: JSFunction -> (JSObject | JSException)
Or however you spell it in Elm.
Admittedly, if Elm is lazy like Haskell, you need some way to deal with the fact that Javascript functions are impure.
[1] http://elm-lang.org/ [2] https://en.wikipedia.org/wiki/Elm_(email_client)
Even if you somehow meant it in earnest, which wouldn't make sense here, it exposes you as someone who couldn't even be bothered to click the OP link.
I'm not even sure I've ever seen a HN submission about the email client. And they're in such different niches that you, precisely, have to write a comment without clicking in to the article. At which point, what value are you contributing to the discussion?
You're basically suggesting that choosing a different name would increase the odds of someone being more relevant when writing a comment based on a submission title. Not very compelling. These comments just get downvoted where they belong.
One of the worst aspects of HN are top-voted arguments that have nothing to do with the subject matter of the article. We don't need more of those.
Have you seen Evan? He's like 12. (Sarcasm because I'm 45 and now everyone around his age looks like 12.)
It screams of needing some sort of governance and RFC process ( edit: seems that there is an RFC process [1]) so that all parties could make their case.
The Angular 1 -> 2 transition should be a lesson to most that if you leave your users hanging, they'll go find another ecosystem.
[1] - https://groups.google.com/forum/#!forum/elm-dev
There's also big examples like Perl 6 and Python 3.
IMO, you can make breaking changes as long as it's done gradually and you provide a clear migration path. After experiencing React's strategy [0] for a few years, I'd say it's become my gold standard for how breaking changes should be made.
[0] https://reactjs.org/docs/design-principles.html#stability
In a perfect world (according to me), Elm would have 5-10 people in its core team, with at least a few of those tasked with triaging issues and PRs. That wouldn't mean "giving up" control of the language and its future.
That would be amazing, but I see this being very similar to Node in its infancy. It took a fork (io.js), and a lot of strong opinions to get Joyent to relinquish its grip on the ecosystem.
I think what the developers who forked Node into io.js showed was competency and care with regards to progress. I'm not sure that could ever happen in the elm ecosystem due to it being somewhat small and niche.
It seems to me that the extreme BDFL governance of Elm is also its strong point at the expense of being then limited to that bandwidth, it's weak point.
Unfortunately, delegating work does not come for free and a great deal of energy will be burned in people management. Unless you're clairvoyant, it can't be said whether that would be any better for Elm or mire it in an even thicker mud.
Elm has a lot of unknowns that someone has to sit down and make decisions about because it wants to generalize over environments beyond browser-side Javascript. I think that sits at the root of why you can't just delegate out core contributor access.
But trying to do that generalization in the first place is also why Elm has some really interesting potential in the long run than just another SPA abstraction.
I read the GitHub issues linked in the OP of that thread. Two are feature requests, and one is a bugfix for a behind-the-scenes problem which apparently has no noticeable symptoms. I understand OP's frustration that these haven't been merged or closed; nobody wants to do workarounds, and everybody wants feedback when they post on GitHub. I'm also personally sympathetic to the idea that Elm core libraries should have more frequent minor releases, which I agree with.
The thing is, I also understand that when open source authors prioritize engaging on GitHub, that implicitly means not prioritizing other things. People think "how hard can it be to write one sentence of feedback as to whether this will get merged?" but that's not how GitHub works socially.
An under-appreciated reality of OSS is that maintainers have two options: engage in a back-and-forth with issue posters until the issue is resolved to the poster's satisfaction, or brace for complaints that you're unresponsive. If authors conclude other priorities are higher than seeing that issue through to its eventual conclusion - however much time that may take up - it's understandable why they wouldn't even begin that conversation in the first place.
(Naturally, those who prioritize responding on GitHub are subject to complaints that ambitious long-term projects are taking forever and perhaps deserve to be labeled vaporware.)
If you have a BDFL, some will say things are moving too slowly because the BDFL doesn't have enough bandwidth. If you have a committee instead, some will say things are moving too slowly because there's too much bureaucracy. Trade flexibility for guarantees? Some will call that stifling. Trade guarantees for flexibility? Some will call that dangerous.
We programmers have every possible combination of preferences, and those whose preferences already align with a given project tend not to bother posting about it online - because they're off happily using the thing that's worked well for them. I think this is why I've found contributing to open source consistently rewarding but frequently exhausting.
For reference, here's what Evan said about the big picture topic here: https://www.reddit.com/r/elm/comments/73ubxo/an_explanation_...
A lot of this boils down to figuring out a delegation model that works for Elm.
Does the BDFL of the language really also need to be the only person maintaining core libraries? The only person maintaining project communications?
In this particular case it feels like the Elm team is afraid of "losing control" over the language.
That's often in direct contradiction with the project becoming more popular, so for a while maintainers need to choose between advocating the thing they're building and advancing it in the way Elm is currently being advanced.
Once things like [1] start appearing in the codebase you're basically asking people to fork your project and what happens after that is unknowable ...
[1]: https://github.com/elm-lang/elm-compiler/blob/d07679322ef5d7...
You have to be okay with that to use it in production. Else you would have used something more stable instead of decided to gamble.
I think Elm is still too early to bike-shed over governance model. And people seem to think Elm is a lot farther along than it really is. Else they wouldn't have the expectations that they do. Or they wouldn't go "I don't have these issues with React."
I think the social issues Elm has are just what it's going to take if Elm wants to arrive at something more compelling that just another language. If there's a continuum with BDFL on one side and design-by-committee on the other, then you're going to have issues no matter where you move the needle.
The upside of the bus-factor-of-1 approach is that you have a visionary in the Hickey hammock. And the unavoidable downside is that you have to deal with the bandwidth of one person which describes a lot of the social issues.
I think that anyone who is uncool with that reality chose the wrong language. And a lot of the criticism that results from that, like this: https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing..., starts to reek of the hot air of entitlement, to use Rich Hickey's words.
I agree. This is harder than people think; we've tried some delegation models in the past that didn't go well, and we reverted back to the way things were previously.
We're still trying new approaches. The next release will have a core module (Array) written and maintained by a community member (Robin H), and I predict the debugger will be the next core project to fully transition ownership from Evan to a community member.
If these go well, they can be models for future delegation to community members!
> you're basically asking people to fork your project and what happens after that is unknowable
It's pretty predictable though - forks basically always fizzle out unless it's major contributors splitting off (as was the case with io.js), and there aren't factions like that among Elm's most prolific contributors.
Turns out it's a lot of work to make something people really want to use!
They should be.
Different trade-offs were made.
Their goals might align quite a lot (functional programming for the browser; compiling to JS), but Elm seems to me more "pure" than ReasonML, and places extra emphasis on correctness ("no runtime errors").
For example, ReasonML allows you to put JS code inside its source [1]. Which might be great if you want that escape hatch, but might mean that runtime errors are common when working with ReasonML. Elm trades a bit of convenience for the enforced reliability.
[1]: https://reasonml.github.io/docs/en/interop.html
And for people who supposedly have so many lines of an alpha language in production, why are you confused about how Elm is being developed? I'm not even using it, but just an interested follower, and it's been pretty clearly explained how he plans on developing it. A couple highly visible threads here and there (some in quite poor taste too) and you are bound to have been given solid, well thoughout references to why Elm is developed this way. I've seen tons of disclaimers that you are using an alpha language in production at risk. No one was misled.
But honestly to me it seems the elm community wants to have their cake and eat it too. Of course that is not a trait unique to them.
As somebody not involved with elm I mostly get to hear about the language from the marketing side. And it does get advocated as production ready (or as least as production ready as anthingthing else in the js world, to paraphrase some talk) and the alpha status, it being still a young language and use in production at own risk only ever seems to really come up when there is some push back.
E.g. I can't see any mention of being "alpha" or warnings on the elm website, besides the version number indicating it. Instead it says things like "elm guarantees no run time exceptions in practice", but when I go to Github issues, I find several of them, including intentional and accepted ones.
It seems to be a neat language, but for now I'll just stay away from it and let them do their thing.
edit: grammar, wording.
https://github.com/elm-lang/elm-compiler/blob/master/LICENSE
Actually, what IS that license? Is it completely unique and not one of the more standard ones?
Reading through the thread, others don't want to fork because it would split the community of an early language. They don't want to take Elm in a different direction, just bugfixes.
This is of course a laudable goal but I think that clashes with the complexity of the real world.
A consequence of this is that if you want to do something Evan spent time designing a solution for you're going to have an awesome experience, he is a great designer, but on the other hand as soon as you try to do something different you're out of luck.
This has the nice effect that what's there is really nice but there is no middle ground and you either get something that is well deisigned and extremely polished or nothing at all.
There are just too many cats that can be released from the bag that would be too hard to reverse once out in the ecosystem. Classic example would be allowing native modules into http://package.elm-lang.org/.
This puts you in a position of treading cautiously with the long-term in mind while your users may clamor for quick fixes that jeopardize the overall strategy.
So I agree with you. This results in the "something good vs nothing at all" release cycle that you point out, but I think its a more accurate explanation of why that is.
The rest of the issues seem to be related to his limited bandwidth. And I suspect Elm is tied so much to his bandwidth because such fundamental design is still being decided.
This. For the good and for the bad Elm's creator seems to be a perfectionist and every perfectionist is a control freak (I'm a recovering one). If you read the Elm newsgroup you'll see that he even controls the website design. By the other hand - if we wait some years - we have a good chance of getting a great language.
Nothing in Javascript / HTML is very stable--I've hitched my wagon to so many stars that burned out. Everything from XSLT to JQuery to Bootstrap. So the fact that probably, something will replace Elm doesn't bother me.
It works now, it's stable, and it hides most of the crap from me so I can just code. It helps that I've been a "Functional Programmer" since 1980 when I first learned LISP, and that our core products are done in Erlang and F#.
I actually like the pace of releases and lack of frequent breaking changes. I'll put some projects aside for 6 months here and there, then come back to them when I have time. Most rapidly-evolving frameworks require you to update all your libraries and fix a ton of breaking changes when you don't touch them for a few months (I'm looking at you, Swift). After I spend all that maintenance time, I often wonder at the value of those changes in the first place. Were they really changes that buy me new flexibility with the language? Or were things just renamed and shuffled around with syntax changes made for no great reason?
When talking to people about using Elm, I discourage them from using it if they're the kind to obsess over the release cycle of a framework that's stable today and that allows them to get quality work done.
I don't mind that 0.19 is taking long time to be released, what bothers me is that there are no bugfix release for 0.18
But at least in the linked discussion, the pace of releases doesn't seem to be an issue, but the lack of communication about what is happening. No clarity whether native extensions will work, if pull requests opened years ago will be merged or at least responded to, whether there will be bug fix releases, etc.
To me it seems, that elm community uses this straw man making it about people just wanting faster release cycles in response to valid criticisms in every unpleasant reddit thread I've have ever seen. Not pointing at you here, since you are not mentioning specific cases.