1. 70

  2. 15

    I expected a bitter rant, but it touches on cultural problems in open source. Open source projects often begin by scratching an itch of its initial creator. That is the nature of open source. As the project grows, others with an itch to scratch join. And that is where it becomes difficult because project management enters the picture. When it is no longer an individual project, it is no longer feasible to address only the problems known to the originator, but to other users as well. It is obvious that Elm hasn’t managed to cross over from the originator’s perspective to a more holistic one, as evidenced by the privileges given to core contributors encoded in the software itself. Maths and i18n are obvious examples: since they’re not interesting enough for the Elm core team, they are externalised as non-interesting, nice-to-haves, whereas the personal priorities of the core contributors can bypass those rules.

    1. 5

      It’s all about empathy for your fellow developers. I maintain the redis-store gems for Ruby, typically used in most Rails apps for cache/session storage. For the most part I’m not affected by the changes made by other contributors, nor are most of the users. Many of them are relatively specific to a problem one is trying to solve, or they’re trying to make things a bit more convenient for a specific workflow. Regardless, I feel that it’s my duty to be empathetic to their problems, and not just reject everything that doesn’t have to do with the majority use case.

      I’ve wondered for a long time why Elm doesn’t get more attention. Surely, this project (which was very ambitious many years ago) must have reached some sort of maturity by now? Why aren’t more people using Elm? This post has somewhat answered my questions. It turns out that Elm is preventing people from using Elm. Who would have thought? :)

      I don’t really understand the reasoning behind their decisions, at all. I get wanting to maintain control over your own project, but news flash: once it’s open source, you don’t get that luxury anymore. Once others are able to criticize and even change your code to suit their own interests, you’re no longer in control. That’s just how open-source, freely developed projects work. Additionally, their resistance toward allowing JavaScript in Elm code just seems obstructive for the sake of it. If most of the reusable front-end code in the world is being developed in JavaScript, and published to NPM, why wouldn’t you want access to that ecosystem?

      Elm should take a cue from the Rails team. They don’t discuss their plans for future additions to the framework in the open until they have stitched together a solid design and announce it formally. Most of the time, some kind of gem is made available for users to test it on their own apps. These users come back with bugs and feature requests, and over time become contributors to the project themselves. This is probably the best way of maintaining some level of control over your project’s roadmap, while still allowing users to have the freedom that they’re used to from projects.

      The idea that Elm is trying to control the narrative here is just hilarious to me. It’s like they’ve learned nothing from Barbra Streisand

      1. 1

        Elm should take a cue from the Rails team. They don’t discuss their plans for future additions to the framework in the open until they have stitched together a solid design and announce it formally.

        Could you clarify this part? Does the rails team discuss the roadmap in an internal mailing list that is not open to the public? If so, I’d be surprised by it - because open source projects normally have public discussions forums, which includes the public issue tracker.

        1. 2

          I believe the core team uses Basecamp to communicate future roadmap proposals, but uses a mailing list and of course GitHub issues to communicate that to the public. But, for example, it’s not like the Rails community had any direct input on the initial (prototype) development of stuff like ActiveStorage or ActiveJob prior to them getting released as gems and the core team saying “here’s what we got. how can we make it better?”

          Obviously this stuff comes from a ton of indirect feedback over the years, as well as the core team keeping a close eye on the kinds of apps people are building with their framework, and when they need to turn elsewhere to solve their problems.

    2. 17

      This matches my impression pretty well, and I think it’s well argued.

      On a technical note, it’s possible to work around the restrictions in Elm 0.19, as I “had” to do to get access to Intl myself:

      1. 21


        From its readme:

        Note: Best not talk about this on the offical Elm channels unless you’re trolling.

        I find this extremely concerning.

        1. 3

          I find this extremely concerning.

          What do you mean?

          1. 8

            If the mainstream Elm community is speech-policed to the point where discussions of alternative tools are suppressed, then the community will not be able to accurately perceive if there are real deficiencies in the tools they build, because nobody will raise objections in-band. Instead, people get frustrated and write essays like the one linked in OP.

      2. 12

        The leadership style in Elm is extremely aggressive and authoritarian. By that I do not mean impolite or rude. It is almost always very civil. But still ultimately aggressive and controlling.

        I had a similar encounter with one of the Elm core members. They were offended by something innocuous I said, and in response they became very aggressive, but couched their words in the language of politeness. It was weird to watch.

        If anyone is considering switching away from Elm to something similar, and would prefer it to be Haskell based, I heartily recommend Miso: https://haskell-miso.org/. And for anything advanced you can always use reflex and obelisk.

        1. 12

          What I don’t get is why this type of stories about Elm is so reliably posted and upvoted, even though they’re all about the same two issues that aren’t really technical and have been discussed ad nauseam here and in other forums.

          There are far more interesting things happening. For example, the other day a new version of elm-review came out. elm-review is a static analysis tool with rules written in Elm. Seems more relevant to Lobste.rs.

          I don’t see many stories about Elm on here, but when one of these pops up, I know it’s going to be posted and upvoted.

          1. 23

            If you think they’re more relevant, then post them! There are plenty of “topic” posters here and they usually do just fine.

            1. 22

              I think these stories get upvoted because a lot of people here are bitter, like I am. I was a very heavy Elm user with tens of thousands of lines of code across many projects in Elm + Haskell with extensive bindings between the two. All of that effort and time spent teaching people Elm and getting it adopted by coworkers/collaborators were all trashed. We had to throw away everything we built. All because of an arbitrary decision to cripple the language.

              In my opinion Elm is now a toy language completely unsuited for any serious development. You cannot bet your company on a language where the answer to a missing library is “wait and see if the devs will take you seriously one day”.

              Sorry! I’m one of these people that upvotes these posts :)

              1. -9

                Well, you can sure hold a grudge! We’re talking about events from two years ago. The thing is, while upvoting these stories might give you and others a sense of vindication, it’s not really helping with the quality of content on Lobste.rs, in my view. There is little value in endlessly rehashing old issues that are not even technical in nature. So perhaps take that into account next time?

                1. 17

                  This was a pretty rude reply to my very nice comment! Maybe you should take that into account next time?

                  The relationship between open source projects and developers is an ongoing discussion and obviously is of interest to everyone. As evidenced by the fact that people are reading and upvoting this.

                  1. 4

                    Aside from your lack of empathy with people who had to throw away their hard work, what I don’t get is why would you engage with Lobsters content that you personally don’t like. Not everything is for everyone, people who personally don’t like some topics here normally don’t question why it’s even here, they just keep scrolling…

                2. 13

                  I’ve read and dismissed other examples of elm griping, but I think this one is very articulate and argues its case very well. I’m convinced on most points where I wasn’t before.

                  1. 7

                    I think people should be warned about this over and over again. It’s more beneficial to the innocent bystander to know about this weird situation that’s unique to Elm than some new release of some Elm library. People should have an idea about what they’re risking by choosing to invest in Elm.

                    1. 4

                      I’m not using Elm at the moment (just not doing front-end), but I’d be pretty happy to upvote them if you posted interesting Elm stories here. Anyway, I agree that this one isn’t especially interesting, but it seems on-topic enough. It also didn’t scare me away from the language.

                    2. 7

                      To anyone else wanting to move away from Elm:

                      I recommend looking into PureScript as an alternative. It’s a much more capable functional programming language, akin to Haskell for the web, and the community is full of mature, respectful adults.

                      Learn more: https://www.purescript.org/

                      Discourse: https://discourse.purescript.org/

                      1. 4

                        I tried Purescript about a year ago, as an Elm replacement. It’s indeed very Haskell-y, but I found documentation and working(!) examples extremely lacking. I gave up after days of fighting to get a working prototype.

                        I recently use nim to do some simple web stuff, and that was maybe not as great, but it was easy for me to get something working. Hours compared to days in purescript.

                        That’s my experience. I have very, very little patience for over-abstracted code and obtuse libraries in general, though.

                        1. 2

                          Mint might be nice alternative as well (when it reaches 1.0 of course). Written by person who moved away from Elm. Less Haskell-y than Purescript/Elm.


                        2. 4

                          There were parts of the “Entitlement and expectations” section that I agree with, but other parts I didn’t (and/or found extremely odd). This was one of the stranger paragraphs:

                          This means that even if a single person wrote every line of code of a language’s compiler themselves, when it comes to thinking about the project, they need to think of themselves as stewards and not owners.
                          (emphasis author’s).

                          It seemed like the author intended that whole section as a guard against claims of entitlement, but.. if taken alone, I found that entire section made me think the author was possibly more entitled than if it wasn’t present at all! Weird!

                          1. 8

                            The first-order understanding of the situation is the classic “you gave me this for free, and it didn’t work for me, so you should fix it”. This is a clear misunderstanding of the transaction involved, and doesn’t help anyone with anything.

                            The second-order understanding is “I gave away a thing for free, and therefore I don’t owe anyone anything.” This is more correct than the first-order understanding, but is still not complete. Even if I give away a thing for free, I’m probably still using a compiler I got for free, and project-hosting I got for free, and my docs are on a web server I got for free, etc. Just because I don’t owe anything specifically to the person who’s complaining doesn’t mean I don’t owe anyone anything.

                            The third-order understanding would include other transactions the user was involved with, like maybe they previously helped answer support questions on a mailing list or something. The fourth-order understanding would include other transactions the dev was involved with, like maybe they previously asked support questions on some other mailing list. TFA is trying to describe an Nth-order understanding as N tends toward infinity: in the open-source community, everybody who’s ever helped anyone has helped everyone, just a little bit.

                            TFA very specifically isn’t saying “the Elm devs gave me a thing for free and, and it didn’t work for me, so they should fix it.” Instead, they’re saying something like “the Elm devs don’t have to listen to me, but they should listen to somebody”.

                          2. 3

                            I think there is a real problem with the interpretation of open source and open governance, which causes much harm. Expectations are often too high for people who interpret “open source” as something else.

                            1. 3

                              Although I’ve considered trying Elm in the past, I have no experience using or contributing to it. After reading the blog post and the comments both here and on the blog I have come to the sad conclusion that what we are dealing with is a full on cult - complete with omniscient leader and insular inner circle of sycophants. I would have thought this sort of thing to be impossible in the world of open source software but hey - hard work and perseverance… There is no chance in hell I would go anywhere near Elm now.

                              Edit: I draw my own conclusions regarding this. It seems painfully clear to me that the blog goes out of its way to avoid any characterizations of cult-like behavior.

                              1. 2

                                I had heard a similar story, but a much shortened version which was Elm took out the escape hatch to vanilla Javascript and went from a production language to a toy language living in its own world. Promising to eventually do “all the things”, but in practice disallowing early adopters from getting work done. Seems like self inflicted damage, coming from a hope that they could encompass all of a potential user’s need within their safe language.

                                1. 2

                                  Yet another instance of a common trope used against Elm:

                                  1. It doesn’t do what I want (almost always “native JS”)
                                  2. I asked to have it included
                                  3. (optional) and I even wrote a patch for it
                                  4. And even though I’m right, the maintainer won’t budge

                                  We understand: Elm doesn’t jive with your style. That’s not an indictment of Elm, just as it’s not an indictment of you. You can move on without disrespecting how someone else wants to run their project.

                                  1. 36

                                    As a potential user of Elm, this “disrespect” is helpful to me. It tells me not to use Elm to write anything that might ever need to call an unpopular library, because those libraries will probably never be written. As a potential open source project leader, it also told me of a failure mode to avoid in my leadership. So I am glad the author didn’t just move on and stay silent.

                                    You suggestion to move on without saying anything would make more sense if Elm prominently advertised that it has its own “style” that is different from most other open-source languages. Like if the Elm home page had this:


                                    • No runtime exceptions.
                                    • Purposely-limited JS bindings, incentivising the community of Elm developers to recreate JS libraries as safe, pure-Elm libraries.
                                    • Opinionated core devs who don’t accept feedback or patches, allowing Elm’s design to be completely coherent.

                                    But Elm’s website doesn’t advertise that. So I think you can’t blame a user for assuming that Elm works like most other open source languages, then feeling bait-and-switched when it doesn’t.

                                    1. 3

                                      For anyone acquainted with JS, I think “no runtime exceptions” pretty well implies your second bullet point (after the “…”), and then the third sort of naturally follows. So, OK, not everybody can read between the lines or read up on third-party opinions about a language before adopting it, but I think I can detect a double standard here. Maybe it’s because of all the effort that the Elm devs put into making the language beginner-friendly?

                                      For what it’s worth, I’m glad that Elm is run the way it is, and I don’t agree that politely not accepting paradigm-breaking contributions is a “leadership failure” let alone “aggressively authoritarian”. There are no lack of alternative languages in this space!

                                      1. 16

                                        For what it’s worth, Elm being run this way means it will never be a consideration for me for anything but the silliest of side projects. I can’t in good conscience encourage anyone at work to use a language like this in production.

                                        I think the most scathing indictment here is not “politely not accepting paradigm-breaking contributions,” it’s the swiftness with which contrary arguments are not tolerated. It’s one thing to grumble out shit-posting or people who argue for the sake of argument. But banning people for suggesting a way to get around single-channel package management or DRM-ed library wrappers? Human endeavor is rife with geniuses and their brilliant ideas getting lost in pursuit of pure paradigms.

                                        And yet, the Elm core team are free to do whatever they want. I’m just never going to make the mistake of using it for something important to me.

                                        1. 2

                                          So, Elm has always had the ‘no runtime exceptions’ promise, and up until 0.19 it also always allowed Kernel code (or equivalent native javascript) to be written as an escape hatch. Furthermore, the ports method does not involve any kind of subprocess isolation, so there can still be runtime exceptions propagated from the javascript dealt with through ports to the ‘elm process’. So, clearly there is no implication there in the way you want there to be.

                                      2. 12

                                        It’s not really a trope though, as the author says, it is hobbled by design.

                                        I evaluated Elm for a side project a few years ago and ultimately made the decision that I didn’t feel comfortable shipping code in it, due to these sort of community horror stories. Continuing to inform people so they can re-evaluate if the community has adopted a more nuanced stance on glaring issues is important.

                                        It doesn’t do what I want (almost always “native JS”)

                                        I don’t think support for localStorage is a unrealistic expectation for production, which is defended with the same sort of nonsense these articles say pervades the community:

                                        Programmers may store important information on thousands of computers out in the world, and losing that data could hurt their business.

                                        If you are storing mission-critical information that needs resiliency in localStorage which can be reset or cleared by browser vendors, you have bigger problems than if you got your localStorage-wrapping API correct or not.

                                        The argument made against having an API for localStorage is exactly the kind of stuff I see these posts talking about. It doesn’t have the “blessing” so it shall not pass.

                                        1. 2

                                          I think you may have missed some important context from your quote. With the preceding sentence:

                                          If a library like this is released, it will need to be supported forever because we cannot just switch to a better API when we figure it out. Programmers may store important information on thousands of computers out in the world, and losing that data could hurt their business.

                                          No nonsense here. They aren’t saying that localStorage is somehow unworthy of blessing, but rather that they’ve put a bunch of work into supporting it, don’t think it’s ready yet, and won’t release a half-baked version that they don’t want to support. Meanwhile you can use the ports to do all of this kind of stuff. I have, it worked fine.

                                          1. 8

                                            localStorage has been around since IE8, the API is small, and the type signatures are simplistic; keys and values are both strings.

                                            The only “tricky” issue that runs counter to their guarantee of no runtime errors I’ve encountered would be certain browsers (looking at you Safari) throw an exception when interacting with localStorage in an incognito context, the other errors, like QuotaExceededError are generally well documented.

                                            There are significantly more difficult browser APIs to encapsulate, so the argument does really hold water when you inspect it.

                                            This sort of argument made in the README is the same sort of civil aggression noted by others many times over at this point, which makes the ecosystem hard to use in reality.

                                            Don’t get me wrong I think the compiler messages elm offers are the best i’ve ever seen and I wish other languages would follow suit, but unfortunately the project has many well enumerated issues at this point.

                                            1. 1

                                              Fair enough. I think all parties agree that Elm isn’t for everybody, and its culture is pretty different than most language projects of its size. I think it’s a refreshing difference, myself, but I’m not invested enough to get emotional about it. I also haven’t seen any of this “aggression” in person, so perhaps I shouldn’t judge.

                                            2. 5

                                              Even that context doesn’t really make sense–why would programmers lose their data if Elm were to remove the old localStorage API and ship a better one?

                                              1. 1

                                                Presumably, the new one wouldn’t be backward-compatible, just because they don’t want to support that. The way I read it, it’s just about who’s responsible when the API breaks. Roll your own using ports (as they suggest), and it’s not their problem.

                                                1. 1

                                                  If they break the API you can still roll your own using ports or just use plain JS to access you existing localStorage data, you don’t lose the data.

                                        2. 2

                                          I thought everyone had switched to mutt years ago…

                                          1. 3

                                            Nobody I know switched straight from elm to mutt. Most went to pine first.

                                            1. 2

                                              Same here, Pine Is Not Elm was the mail reader of choice for my peers. I believe the client I used was mh, but it’s been a looooong time.

                                              1. 2

                                                Ahh I switched from pine to elm and then mutt.

                                              2. 1

                                                Any link to that? Couldn’t find anything but the email client…

                                                1. 5
                                                  1. 2

                                                    That’s the (terrible) joke.