Do we need to move away from Elm?
reddit.com
reddit.com
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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#.
[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.)