9 ms·

Do we need to move away from Elm?

168 points by sridca 9y ago

shaki-dora 9y ago
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.
- RubenSandwich 9y ago
  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.
  - rs86 9y ago
    The same occurred to me, Evan is brilliant, but elm having one developer only is a risk
  - steinuil 9y ago
    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.
- Lazare 9y ago
  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.).
  - dennisdamenace 9y ago
    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.
    - Hurtak 9y ago
      How would you define "fail" in such bet?
tazjin 9y ago
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. We'll see how it works out ... [1]: https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing_elms_momentum/ https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing...
danharaj 9y ago
There's a fairly direct migration path from Elm to Haskell + reflex, though it's much less user friendly. You'll have no technical limitations tho.
- thepratt 9y ago
  There's PureScript to add to the list as well.
- davidgl 9y ago
  Or https://fable-elmish.github.io/elmish/ https://fable-elmish.github.io/elmish/ on Fable.io. F# and Elm are very similar.
Athas 9y ago
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 http://reasonablypolymorphic.com/blog/elm-is-wrong
skybrian 9y ago
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.
rishav_sharan 9y ago
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.
- dennisdamenace 9y ago
  I’ve been using Elm since 0.16. Development is slow and thoughtful. Perhaps 0.19 will be a disaster, but I doubt it. 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.
  - archgoon 9y ago
    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.
    - always_good 9y ago
      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.
cperciva 9y ago
The most recent release of elm was over a decade ago. If there's anyone left still using it, I'd definitely recommend switching to mutt.
- rkwz 9y ago
  I think it's about the Elm language [1] not the email client [2] [1] http://elm-lang.org/ http://elm-lang.org/ [2] https://en.wikipedia.org/wiki/Elm_(email_client) https://en.wikipedia.org/wiki/Elm_(email_client)
- always_good 9y ago
  People make this joke every single time Elm comes up. 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.
  - acheron 9y ago
    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.
    - always_good 9y ago
      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.
    - 9y ago
olingern 9y ago
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. [1] - https://groups.google.com/forum/#!forum/elm-dev https://groups.google.com/forum/#!forum/elm-dev
- TheAceOfHearts 9y ago
  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. [0] https://reactjs.org/docs/design-principles.html#stability https://reactjs.org/docs/design-principles.html#stability
  - olingern 9y ago
    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.
  - earenndil 9y ago
    Eh, python 3 wasn't really fundamentally different from 2, it just had some breaking changes and aside from that was an upgrade.
- dennisdamenace 9y ago
  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.
- 9y ago
stesch 9y ago
I tried Pine for a few months but ultimately changed to mutt. But today I'm using Thunderbird.
deleted 9y ago
[deleted]
rtfeldman 9y ago
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. For reference, here's what Evan said about the big picture topic here: https://www.reddit.com/r/elm/comments/73ubxo/an_explanation_of_elms_policy_on_native_code/ https://www.reddit.com/r/elm/comments/73ubxo/an_explanation_...
- tazjin 9y ago
  Some loose thoughts: 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/d07679322ef5d71de1bd2b987ddc660a85599b87/compiler/src/Elm/Package.hs#L72 https://github.com/elm-lang/elm-compiler/blob/d07679322ef5d7...
augbog 9y ago
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?
- always_good 9y ago
  About as much as any two different approaches to a problem achieve a solution to that problem. Different trade-offs were made.
- mjaniczek 9y ago
  (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. [1]: https://reasonml.github.io/docs/en/interop.html https://reasonml.github.io/docs/en/interop.html
  - StreamBright 9y ago
    Yep, this is exactly why we use ReasonML instead of Elm. I want to be able to write inpure code when I need it.
chasote 9y ago
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.
- smoe 9y ago
  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. edit: grammar, wording.
pmarreck 9y ago
Is there a licensing reason why someone couldn't just fork Elm and come out with a new less-dictatorial leadership-driven project? https://github.com/elm-lang/elm-compiler/blob/master/LICENSE 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?
- nemothekid 9y ago
  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.
  - electroly 9y ago
    It's the three-clause BSD license with the words "the copyright holder" replaced with the author's name.
msangi 9y ago
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.
- always_good 9y ago
  I liken it more to Evan investing "hammock time" (https://www.youtube.com/watch?v=f84n5oFoZBc 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/ 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.
- galfarragem 9y ago
  > 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.
Bitcoin_McPonzi 9y ago
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#.
crusso 9y ago
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.
- msangi 9y ago
  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
- smoe 9y ago
  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.
- 9y ago
rs86 9y ago
I don't get why not making it an option not to install "unsafe" modules
boubiyeah 9y ago
Elm was a nice experiment, but people need to put things in production and be confident they can fully maintain all of their code and dependencies.
mrbill 9y ago
I hate duplicate-named projects. Thought for a moment this was about someone discussing upgrading their text-based mail client.

168 points by sridca 9y ago

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.

RubenSandwich 9y ago
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.
- rs86 9y ago
  The same occurred to me, Evan is brilliant, but elm having one developer only is a risk
- steinuil 9y ago
  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.
Lazare 9y ago
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.).
- dennisdamenace 9y ago
  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.
  - Hurtak 9y ago
    How would you define "fail" in such bet?

tazjin 9y ago

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. We'll see how it works out ... [1]: https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing_elms_momentum/ https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing...

danharaj 9y ago

There's a fairly direct migration path from Elm to Haskell + reflex, though it's much less user friendly. You'll have no technical limitations tho.

thepratt 9y ago
There's PureScript to add to the list as well.
davidgl 9y ago
Or https://fable-elmish.github.io/elmish/ https://fable-elmish.github.io/elmish/ on Fable.io. F# and Elm are very similar.

Athas 9y ago

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 http://reasonablypolymorphic.com/blog/elm-is-wrong

skybrian 9y ago

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.

rishav_sharan 9y ago

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.

dennisdamenace 9y ago
I’ve been using Elm since 0.16. Development is slow and thoughtful. Perhaps 0.19 will be a disaster, but I doubt it. 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.
- archgoon 9y ago
  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.
  - always_good 9y ago
    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.

cperciva 9y ago

The most recent release of elm was over a decade ago. If there's anyone left still using it, I'd definitely recommend switching to mutt.

rkwz 9y ago
I think it's about the Elm language [1] not the email client [2] [1] http://elm-lang.org/ http://elm-lang.org/ [2] https://en.wikipedia.org/wiki/Elm_(email_client) https://en.wikipedia.org/wiki/Elm_(email_client)
always_good 9y ago
People make this joke every single time Elm comes up. 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.
- acheron 9y ago
  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.
  - always_good 9y ago
    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.
  - 9y ago

olingern 9y ago

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. [1] - https://groups.google.com/forum/#!forum/elm-dev https://groups.google.com/forum/#!forum/elm-dev

TheAceOfHearts 9y ago
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. [0] https://reactjs.org/docs/design-principles.html#stability https://reactjs.org/docs/design-principles.html#stability
- olingern 9y ago
  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.
- earenndil 9y ago
  Eh, python 3 wasn't really fundamentally different from 2, it just had some breaking changes and aside from that was an upgrade.
dennisdamenace 9y ago
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.
9y ago

stesch 9y ago

I tried Pine for a few months but ultimately changed to mutt. But today I'm using Thunderbird.

deleted 9y ago

[deleted]

rtfeldman 9y ago

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. For reference, here's what Evan said about the big picture topic here: https://www.reddit.com/r/elm/comments/73ubxo/an_explanation_of_elms_policy_on_native_code/ https://www.reddit.com/r/elm/comments/73ubxo/an_explanation_...

tazjin 9y ago
Some loose thoughts: 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/d07679322ef5d71de1bd2b987ddc660a85599b87/compiler/src/Elm/Package.hs#L72 https://github.com/elm-lang/elm-compiler/blob/d07679322ef5d7...

augbog 9y ago

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?

always_good 9y ago
About as much as any two different approaches to a problem achieve a solution to that problem. Different trade-offs were made.
mjaniczek 9y ago
(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. [1]: https://reasonml.github.io/docs/en/interop.html https://reasonml.github.io/docs/en/interop.html
- StreamBright 9y ago
  Yep, this is exactly why we use ReasonML instead of Elm. I want to be able to write inpure code when I need it.

chasote 9y ago

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.

smoe 9y ago
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. edit: grammar, wording.

pmarreck 9y ago

Is there a licensing reason why someone couldn't just fork Elm and come out with a new less-dictatorial leadership-driven project? https://github.com/elm-lang/elm-compiler/blob/master/LICENSE 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?

nemothekid 9y ago
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.
- electroly 9y ago
  It's the three-clause BSD license with the words "the copyright holder" replaced with the author's name.

msangi 9y ago

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.

always_good 9y ago
I liken it more to Evan investing "hammock time" (https://www.youtube.com/watch?v=f84n5oFoZBc 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/ 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.
galfarragem 9y ago
> 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.

Bitcoin_McPonzi 9y ago

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#.

crusso 9y ago

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.

msangi 9y ago
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
smoe 9y ago
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.
9y ago

rs86 9y ago

I don't get why not making it an option not to install "unsafe" modules

boubiyeah 9y ago

Elm was a nice experiment, but people need to put things in production and be confident they can fully maintain all of their code and dependencies.

mrbill 9y ago

I hate duplicate-named projects. Thought for a moment this was about someone discussing upgrading their text-based mail client.