Why I'm Leaving Elm - <AUTHOR> https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ <comment><USER2> I believe Elm took some major missteps. Despite doing so many things right with the initial designs (and still one of the best designed front-end experiences) it never grew much beyond the early adopters and it basically remained a fun hobby language.

I criticized the basic lack of communication and the infrequent updates in r/elm (I believed these infrequent updates were going to kill the momentum of Elm). I was concerned that it made the language seem stagnant.

Immediately, after posting it was clear it was a major concern by others as well. So what did Evan do with that criticism? He spent the opening part of his European talk mocking it [0].

I didn't take it personally, but it illustrated the kind of mindset Evan has. A good leader would have asked questions about why many feel that way and would have instituted a process for more frequent updates. It became clear to me, outside of being brilliant at designing Elm he is not the person to take it to the next level of adoption. If it's not moderately adopted it won't make sense recommending it for any production project, even if it does many things right.

To me it feels like (sadly) Elm will just be a hobby project despite what it could have been.

[0] [https://youtu.be/uGlzRt-FYto](https://youtu.be/uGlzRt-FYto)

<comment><USER3> I also eventually came to the conclusion that elm Will be forever niche and can't become a mainstream language.

I agree with so much of what Evan says in principle, but every time the project development style is criticized, someone pastes a link of Evan basically telling everyone to sit down, shut up, and wait. Which is Evan's right, but rhetorically speaking, this is horrible. Just a little charm can go such a long way.

<comment><USER4> He's quite charming in person, FWIW, and he has great language design sensibility.

<comment> amw-zero Sounds like that's a complete facade though. Plenty of people are overly polite because it inflates their ego to be perceived as polite.

And the article isn't talking about politeness so much as openness. Which, the Elm team seems very very closed off.

<comment><USER5> >Plenty of people are overly polite because it inflates their ego to be perceived as polite.

Can you point me to some article or rigorous paper that would help me take this claim seriously?

<comment><USER6> I think the idea that most people are nice to some people, and not nice to others is a generally accepted premise.

<comment><USER5> >I think the idea that most people are nice to some people, and not nice to others is a generally accepted premise.

Nothing I said implied I disagreed with that "premise" and it seems bizarre how what I did say could somehow lead to your non sequitur of an answer. At any rate, what should have been obvious I was taking exception to was the idea that "plenty of people are overly polite because it inflates their ego to be perceived as polite." That comes across as reductive. The same argument could be used to criticize anyone's motivations for practically anything and anything's opposite. So and so does x because it inflates their ego to be perceived as doing x or so and so is overly impolite because it feeds their ego to be perceived as someone with a gruff demeanor. It's too easy so I was looking for some kind of article that at least made a convincing argument for its application in at least this specific context. I'm still waiting.

<comment><USER7> Like you said, anyone's motivation for their actions can be questioned. Everyone's motives are questionable. I don't think an article is needed to argue about that. I, personally, am kind to many people just because it is troublesome not to be, or to extract specific behaviors as a return. I managed to get a driving license without bribing (bribing for that is standard practice here), because I was so overly polite and non aggressive during training that my instructor genuinely believed I was one of the few pure souls left on this planet. The instructor then managed to persuade the examiner of my driving test that the reason I was not paying was because I was naive and really thought I could drive making zero mistakes, not because I was trying to get away with it ( if you don't bribe, a single tiny mistake is enough to get cut, and you can't really avoid it if the examiner wishes, also the examiner and the instructor share the bribe). That saved me about 150 euros. That's politeness ft or you.

<comment><USER5> I'm frankly not buying this lazy argument. The assertion that "plenty of people are overly polite because it inflates their ego to be perceived as polite" is bullshit. In it's general form it's no more than a convenient tool to disparage those you don't like. Dislike a person but lack a rational or socially acceptable way to criticize them? Easy, just use this prebaked phrasing to cast any exhibited behavior negatively. Imagine somebody doesn't like happy/serious/polite/flirty/whatever people. Then to them happy/serious/polite/flirty/whatever people are just acting happy/serious/polite/flirty/whatever to be perceived that way as an ego boost. It's an absurdly reductive cynical word game when you need to hate but can't come up with anything substantive. The argument's unprovability short of mind reading and its applicableness to anything (and anything's opposite!) removes any intellectual rigor as it careers completely over the side of "proving" too much. Vacuous rhetorical flourish trotted out in the middle of discussion to target anything the opponent says or does as mere self-aggrandizement. Seductive if one goes for that kind of sophistry however the reality of human motivation does not resemble this arbitrarily contrived model of, to echo the GP, ego inflation. Here's the real reason people seem "overly" polite: a combination of cultural norms, fear, being non-confrontational, and power dynamics. As simple as it is.

I know that some people are willing to go through much mental gymnastics to justify hate and derision while seeing themselves as virtuous but had no idea this mean spirited belief pattern was at all pervasive here, however this discussion has led me to revise that belief. It's sickening but rather than continue to get worked up I'll just log out for another 6 month hiatus like I've done before when this community gets a little too high off its own farts. Hopefully things will be better, folks a little less stir crazy in October. Later.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> This criticism is spot on; it is exactly what I observed in late 2018, early 2019 as well. It's an awesome language, but there is basically a big case of 'vendor lock-in'. Certain compiler features are only available to the maintainers, nor is there any way to use alternative package sites.

I don't want to know what would ever happen if the Elm developers decide to take [https://package.elm-lang.org](https://package.elm-lang.org) offline. That will leave so many projects out there in an unbuildable state. Even if you saved source tarballs of the core packages, there is no way to tie it into the build yourself. The Elm compiler must load it through the official package site.

I would thus personally strongly advise against using something like Elm to build any piece of software that needs to be maintained over time. It's too much of a risk.

<comment><USER9> That's not correct, you can just inline any package into your vendor folder in your project.

And the package website is just an index, the sources need to be on github in the first place (this has some problems too), but if the website is down, you can still grab them from github.

<comment> vaer-k Here's the relevant section from the article for this comment.

[https://lukeplant.me.uk/blog/posts/why-im-leaving- elm/#why-d...](https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#why-don- t-you-just-ing)

</comment></comment></comment><comment><USER10> After reading a large number of the responses here, I feel like I've noticed a pattern - two types of comments:

1) I've used the language and agree with the conclusions of the post even if I don't necessarily agree with every point.

2) I haven't used the language, but I believe open source projects must be maintained by their maintainers as they see fit.

I actually agree with both of these positions, but, having used Elm in the past for a hobby project with an eye towards using it in production, I probably won't ever use it. I loved the original promise. Evan's ideas about the Elm Architecture are worth reading and learning for anyone. But, as many others have pointed out, if one has to maintain a project over the years, the breaking changes in the language would have caused great bouts of teeth gnashing.

I don't love Java, but over the years I've come to expect that with each new major version of the language, that a small amount of work needs to be done to guarantee my production code will keep working and I can integrate new features as I have time. With Elm, every release forced me to spent hours figuring out how to make my old code work again.

<comment><USER11> > But, as many others have pointed out, if one has to maintain a project over > the years, the breaking changes in the language would have caused great > bouts of teeth gnashing.

This isn't just a problem for Elm but for front-end development in general. Not so much because of JavaScript the language, but because of the libraries and, to a much lesser extent, the browser APIs.

In the library and framework space many take semver as license to completely rework their APIs with every major version bump because they "got it wrong" last time around. It's pretty infuriating because in most cases whatever benefits the new API offers are generally fairly marginal and not worth the cost of all the reworking that needs to be done.

I'd always rather an API was stable than perfect because, for one thing, you're never going to achieve that perfection you dream of. There will always be some new use case or better conceptualisation that you didn't think of and, really, all you're doing much of the time is thrashing by pursuing this. To me it often seems like immature software engineering.

I haven't written any Java for a _very_ long time, but I know that C# code I wrote back in 2004 targetting .NET 1.1 would still run substantially unmodified today on the latest .NET runtimes[1] - in fact I'm pretty sure some of it is.

 _[1] Possibly not .NET Core, but certainly the classic runtime._

<comment><USER12> A fantastic example of this _not_ happening in js libraries though is Plotly.js. It's still on a 1.x release and has maintained backwards compatibility (for the most part) with the original API for _years_.

Full disclosure, I used to work there (specifically, on plotly.js).

<comment><USER13> Another is KnockoutJS which went from 2 to 3 with minor changes and virtually nothing broke on 2.x -> 2.x+1 in all the time I used.

I'm kinda sad it (functionally) died out because they clearly valued and worked hard on that.

<comment><USER11> Both Plotly.js and KnockoutJS are great examples of stability.

I think KnockoutJS may still the only (formerly) major framework that focussed only on doing data-binding really well without adding in loads of other functionality. As you say, a shame it died out.

I don't know if KnockoutJS is dead, so much as done or perhaps complete. If all you want is data-binding it might be worth considering. It was released as recently as 5 months ago ([https://www.npmjs.com/package/knockout](https://www.npmjs.com/package/knockout)) and it's still getting the occasional bug fix: [https://github.com/knockout/knockout/pulls](https://github.com/knockout/knockout/pulls)

I suppose it's not that trendy so good luck getting buy-in at a team level, but it would certainly still work for a bunch of different use cases.

<comment><USER13> Agreed on all points, there is an advantage in using whatever is currently flavour of the month though (more documentation, components, better integration with dev tools and such) but I used KnockoutJS for a couple of years and really liked it, it was a massive upgrade over jquery for a lot of UI stuff and brought some much needed sanity.

These days I use either React or Vue in the same role as the world keeps turning.

It's amazing they are still putting work into it for those people with massive codebases dependent on it though, anyone picking that 7-8 years ago definitely made a good bet.

</comment></comment></comment></comment></comment></comment><comment><USER14> I don't agree with everything here. Open source really does mean that you just have all the code to rebuild the thing from scratch under the right sort of license. Open source doesn't mean anything else, like having access to design decisions.

Interaction style and personalities are also not part of the definition of open source; open source doesn't mean nobody is brusque or abrasive. Some communities have additional codes of conduct and social contracts and what not for that sort of thing.

Here is a balanced viewpoint from the GNU Awk and Bash maintainers:

[http://www.skeeve.com/fork-my-code.html](http://www.skeeve.com/fork-my- code.html)

Elm users who are not happy should fork the code --- everything, including the ecosystem's dependencies on an ELM internet domain --- and maybe produce something that is completely self-contained. Software that relies on "phoning home" is a risk regardless of where that is hosted and whether the people are nasty or nice.

If the Elm core developers don't like it and kick people out of their project for forking, you just have to bite the bullet on that.

(From the description of what that project is like, why would you care about being kicked out. Kicked out or not, your 20 line bugfix still isn't getting looked at for another two years.)

<comment><USER15> Agree. I'm gonna be honest and say I haven't finished the entire article so author might have elaborated further after, but I got a chill when reading the following passage:

> The second is that if you advertise something as Open Source, there is a > common set of assumptions about what that means, some of which are explicit > in accepted definitions of the term.

It seems the "common set of assumptions" is around that people can get involved and actually have impact on the direction of the project, but that's not at all included in the actual definition of open source. [https://opensource.org/osd](https://opensource.org/osd)

And I'm starting to see this sentiment crop up more and more recently, where someone open sources something just to share the code, while people expect the maintainers/creators to fit their project to their worldview. I think this misconception is the source of many throwing a fit on GitHub in issues/PRs where the maintainers won't change something based on the user's views.

Open source is and should continue to be about that you are free to fork the code if you don't like the direction. Otherwise, assume nothing from others work they publish for you to use for free.

Edit: I continued reading and found bunch of more passages where the authors understanding of open source seems to be incorrect. Some examples:

> Bu I think this claim is increasingly hard to defend. For me, real Open > Source goes beyond a LICENSE file.

> I'd like to see some kind of openness in the development process before I > considered something to be Open Source

> It seems that Evan and the core team have forgotten that languages, > especially Open Source ones, operate as platforms, and in these platforms > contributions from other developers and reputation are critical.

> Fairness must be a central principle in any Open Source project

While I agree that these things are nice, they are in no way required to called a project Open Source. Open Source is strictly about the software that is under the license, not the community/company around it. The creator and maintainers are free to accept/deny any patches they feel like, and project should still be considered open source, as long as the _actual_ requirements of open source are followed.

<comment><USER16> > I continued reading and found bunch of more passages where the authors > understanding of open source seems to be incorrect.

The author is one of the "core team" members of Django[0]. So, it is safe to say that whatever assumptions he has about open source is not a fantasy and cannot be compared line-by-line to a text book definition of open source.

[0] - [https://lukeplant.me.uk/personal.html](https://lukeplant.me.uk/personal.html)

<comment><USER17> > _cannot be compared line-by-line to a text book definition of open source_

Why not? The OP claims that his opinions are explicitly mentioned in accepted definitions:

> _some of which are explicit in accepted definitions of the term_

If the OP is going to make that claim, why should we not expect to be able to find validation for his assumptions in a written definition of open source?

<comment><USER18> The fact that your quote starts with the word "some" should tell you everything you need to know.

<comment><USER17> It doesn't tell me which or his opinions he thinks are backed up by accepted definitions or what he considers an accepted definition. So no, it doesn't tell us anything. It sounds more like a weasel word to get out of providing citations to back up his arguments.

</comment></comment></comment></comment></comment></comment><comment><USER19> > For example, if there is a bug in any core library, or something missing, > you just have to wait for the core team to fix it, rather than being able to > fix it yourself. You might need a performance fix, which can be done using > Javascript but not in Elm (lack of destructive updates makes some things > very hard to implement efficiently), and again you will be stuck having to > explain to your boss "I know this is possible in Javascript, but we chose > Elm and it makes it very hard".

Hard pass on Elm if this is true. This is an incredibly damaging accusation, is this consistent with other people's experience using Elm?

<comment><USER20> this is, at least, consistent with my experience using elm on a side project. Dropped elm like a hot potato when I hit that wall.

frustrating, too, because I was really enjoying the language, and everything about it up to that point. The tooling support for Elm is REALLY solid compared to some other functional compile-to-js languages out there.

If anyone is looking for a good functional compile-to-js language, I would suggest taking a look at ReasonML or possibly ClojureScript. Personally, I've just been using TypeScript written in a functional way, and it serves my needs at this point.

<comment><USER21> My brief experience has been similar. Elm is a dictatorship that could be wonderful if it didn't exist in the realm of messy html/js. I experience an icky feeling of stockholm-syndrome part of the time, and just plain frustration at other times when dealing with Elm.

What's infuriating is that I _do_ see the benefit of some degree of strict stewardship. It's just that it's too much in this case.

<comment><USER22> The use of "dictatorship" in your comment brought a smile to my face because I thought of the BDFL title given to Python's creator ... and then imagined the Elm team forgot the "B" at the beginning of the acronym. Note that I have no personal experience with Elm and am in no position to take sides. The comment just describes the mental image I got from your comment's ink blot.

<comment><USER23> Most dictators believe that they are benevolent, as does their close circle (which is then often seen as "the community", because it has the loudest voice). From the blog, it definitely sounds like this is the case for Elm.

</comment></comment></comment></comment></comment><comment><USER24> This post resonates with me. I'm not deeply involved in Elm, I just have an Elm side project (started on 0.17) with roughly 1k lines of code.

Do I love Elm? Yes, definitely. It's such a well-designed language. Lots of thought went into it. It's very focused and has great (albeit sometimes non- obvious) solutions for almost everything.

However, the leadership style is also what keeps me from recommending Elm to anyone wanting to create a project that cannot be simply rewritten in case Elm does a change that doesn't work for you. I wouldn't use Elm at work, since it would be a very high-risk situation. (In fact, I was faced with that decision and decided against Elm.) If you face a blocker, you're screwed.

A version of Elm that is being developed in the open, where people are allowed to make suggestions, where all feedback is considered valuable, where people can experiment and explore the design space without artificial limits? Yep, I would _love_ such a thing, and I'd happily contribute.

Until that happens, I'll happily use Elm for small, personal low-risk projects. I do hope that the situation will improve once the "big rewrite" with a WASM backend is done.

<comment><USER25> This kind of leadership gave us Go. It's not necessarily bad. If everyone gets their way with the language specs, then all languages will look like a weird dialect of C++ :)

<comment><USER26> You'll find examples on both sides. Rust is a great example of a successful language growing in the open.

<comment><USER27> Really growing, so much that it's kinda hard to keep up with

<comment><USER26> Oh please, maybe if all you're doing is reading hackernews articles. The language hasn't really changed that much in the last few years. The only major feature is async/await.

<comment><USER28> Rust is a complicated language and still has a very long journey ahead to prove its worth, I have yet to see it being used extensively in Mozilla to re- write Firefox which hasn't happened yet (may not happen as replacing C++ with Rust is a nightmare given most useful systems code is still either C or C++).

Hopefully zig [1], picks up. It's compiled code is smaller and better in performance compared to Rust and also provides a mechanism to write safe code with allocator choices. Also the overall zig language design fits in brain as the grammar is not complex unlike Rust which has a steep and complex learning curve. Rust developer spend a lot of time learning language feature and fighting with borrow checker syntax and still need to rely on unsafe C library to do anything useful. Zig made a conscious choice to make it work with C and realize it needs to work with C rather than replace it unlike Rust which is relying on C and still trying to proclaim as C replacement, when its not yet ready.

[1] [https://ziglang.org/](https://ziglang.org/)

<comment><USER29> Parts of Firefox are already written in Rust:

[https://wiki.mozilla.org/Oxidation](https://wiki.mozilla.org/Oxidation)

they are continuing the work to replace the least performant/secure components in Rust when it's easily possible to switch them out

</comment></comment></comment></comment></comment></comment></comment><comment><USER30> As someone who spent over a year working on a production Elm app, I agree with this post 100%. Our team experienced all of these issues and more.

The true cost of the approach Evan and the core team have taken is hard to measure, since what I observed most was skilled community members with the time and will to contribute silently abandoning the community after their efforts were roundly rejected or ignored. The record of these interactions tend to be scrubbed from GitHub and other community forums.

There are some really great ideas in Elm, but I would never recommend it to someone as a tool for production use. It is run more like a hobby project.

<comment><USER31> I (luckily) only implemented a few smaller projects in elm around the time of 0.18 release.

I started looking into how to get WebCrypto working, and was scared away by how they treated outside contributors. I liked Elm as a language, and Evan made a very good design. But to the core team, I got the message that they intend to work at their own pace, at their own leisure and will probably not take much input from outside contributors. This makes it very hard to expand the community and the usefulness of the language. They still have not afaik released anything for WebCrypto or WebWorkers. It is fine they are committed to the 100% pure language for frontend idea, but it makes it very hard to use if the Gods in the core team does not think it's fun/worthy to solve.

</comment></comment><comment><USER32> For me, the best thing I got from this critique was the link to this 2018 talk by Evan:

The Hard Parts of Open Source, [https://www.youtube.com/watch?v=o_4EX4dPppA](https://www.youtube.com/watch?v=o_4EX4dPppA)

I found Evan's talking style really entertaining and enjoyable, and I totally relate to the first part about "why don't you just..." and "have you thought about delegation..."!

The HN comments here are near uniformly negative towards Elm and supportive of Luke's criticisms. Fair enough, it's a reasoned critique and those are definitely issues that would affect users.

I found the critique informative and useful. I don't use Elm though I've watched with passing interest for a while. Now I feel there are gotchas or expectations I should be aware of if I'm considering using it, about the way the project is heading.

But I felt it came off way more entitled than I'm comfortable, mainly when Luke starts _moralising_ , placing ethical obligations upon Evan.

That came over to me as "you are obliged to do a lot more work that I want you to do, on your own time and personal cost, and to stop developing the project according to your own vision or you are a bad person".

<comment><USER33> > That came over to me as "you are obliged to do a lot more work that I want > you to do, on your own time and personal cost, and to stop developing the > project according to your own vision or you are a bad person".

I mention this in my top-level comment, but here's Rich Hickey of Clojure responding to similar assertions: [https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au...](https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_authority/do1olag/)

> Clojure was not originally primarily a community effort, and it isn't > primarily one now. That has to be ok. The presumption that everything is or > ought to be a community endeavor is severely broken. A true community > respects the autonomy of its participants, else it degenerates into a cult > of need/want.

The people who write these "I'm leaving X" posts must know they have disproportional power in such a tiny pond. Imagine writing the same post about Javascript or Java because you thought it was supposed to be a democracy or something. Nobody would even read your post.

<comment><USER34> Let's take Java as a point of reference, since you brought it up. Imagine the JDK were opinionated about which authors were allowed to write packages that use FFI. And people wanting to use it would be instructed to build a relationship to said authors to get their code blessed to use FFI. It is wholly inconceivable. I'm sure you'd see quite a few "Leaving Java" posts over it.

<comment><USER35> your scenario isn't all that different from how the jdk authors view the use of internal classes, like sun.misc.unsafe.

<comment><USER34> Here's what Oracle says[0]: "Technically, nothing prevents your program from calling into sun.* by name." And I don't think I ever accessed sun.* when writing Java. So the example seems both ill-suited and far-fetched to me.

One of the first things I did in Elm was writing a tiny JS snippet to get a missing piece from the browser. It was something I needed and my site wouldn't have worked without it. I later switched to the Elm implementation once that became available.

Now given the stated goals of the Elm project, I will be unable to repeat this. Which means I expect I'd be stuck if I again wanted to access the browser API before the Elm people got around to implement that part. And that wholly changes my view of the project.

I'm using Elm for a toy project. If I'm blocked, I go do something else. What a pity though.

[0] [https://www.oracle.com/java/technologies/faq-sun- packages.ht...](https://www.oracle.com/java/technologies/faq-sun- packages.html)

</comment></comment></comment></comment></comment><comment><USER36> Arrogant is the most accurate word to describe Elm and its leadership. I tried to use Elm in production between 0.14 and 0.18 versions and it was fun and mind expanding experience. I'm truly grateful that I've used it because it introduced a lot of functional stuff to me. But I no longer use it myself or recommend it for any serious work.

Breaking changes were negligible in the beginning. But I got fed up with rewriting the app after the 3rd Elm upgrade. I think it's irresponsible to advertise the language to be used in production and break it every fucking year. Speeches about finding the perfect solution are great for academical discussions and toy languages, but you can't just remove the stuff that your community uses without offering any alternative. It all stems from the arrogance and cult-like behavior of the core team. I'm sure that they're wonderful and very smart people who do their best to create the best version of the language that they can. But their management style is too dictatorial and they don't respect their community.

For me, the split started with elm formatter discussion on github. I disagreed with some of decisions that the core devs made and I wanted to see what other developers have been saying about it. On of the issues was the preference for 4-space indentations instead of 2-space. I understand that it's important to have a single source of formatting for the language. But at that time there was no consensus on what amount of spaces to use. Basically, the community divided almost 50/50 between the two. Moreover, a lot of core libraries and example code still used 2-space indentation. (that's why I preferred it). Due to lack of consensus, there was a suggestion to add a flag to formatter to set the indentation. It required to change some parts of code to pass the flag to the formatting module. At that moment, one of the core devs stepped up and closed the discussion because he didn't approve of this decision and he just said that 2-space people should adapt to the new 4-space default (that wasn't supported by any majority). It was the first time when I felt that the Elm management is too strict and I don't want to have anything to do with people with such attitude.

<comment><USER37> isn't this the exact problem that tabs solve?

<comment><USER38> Yep! If people used tabs, then everyone can display it how they like and these stupid discussions wouldn't be necessary. Alas, for some reason the world has rallied behind spaces. Sigh.

<comment><USER39> It doesn't really solve the problem. How do you format this code with tabs:

      <TAB><TAB>function name(arg1, arg2,
      <TABs or spaces?????>   arg3 <-- align with arg1)

The other issue is with maximum line length. If you have a maximum line length of 80, do tabs count as 2 spaces, 4 spaces, or 8 spaces towards meeting that line length?

Using spaces ensures that it at least looks consistent, independent of your tabstop settings.

<comment><USER40> > It doesn't really solve the problem. How do you format this code with tabs:

      <TAB><TAB>function name(arg1, arg2,
      <TABs or spaces?????>   arg3 <-- align with arg1)

Just wondering… do you realign the parameters every time you rename a function?

<comment><USER41>
        <TAB><TAB>function name(
        <TAB><TAB><TAB>arg1,
        <TAB><TAB><TAB>arg2,
        <TAB><TAB><TAB>arg3,
        <TAB><TAB>)

That means this never comes up, and you don't need to change adjacent lines because you've renamed a function.

<comment><USER32> That wastes a lot of vertical space if you have a lot of function calls. If you're one of those who prefer that, it's ok. I much prefer:

        function name(arg1, arg2, arg3,
                      arg4, arg5, arg6);

</comment></comment></comment></comment></comment></comment></comment><comment><USER42> We had a pretty similar experience with elm around cookies. The elm- lang/cookie repo README starts with "Cookies are an ancient mistake of web browsers. They make a bunch of security problems quite easy, so consider this an expert library." However, they never address reading cookies, so if you're using a framework that does CSRF protection with cookies, you have to use ports, which adds quite a bit of complexity for something as simple as making an API request.

Elm looks great on the surface, but once you start digging in you really start to realize it's "there" way or else. It's too bad, the ideas have a lot of promise, but we pivoted away quickly after running into the "core arrogance" a couple of times and went with Typescript/React/Redux.

<comment><USER33> Well, you should be using `httpOnly` cookies (i.e. unusable from the browser) and setting them from the server. Your browser client will automatically send them.

document.cookie _is_ a security vulnerability that's hard to find in any respectable documentation. It's up there with sql string concatenation.

<comment><USER43> SQL string concatenation is fine. You mean parameter concatenation (into the query string).

<comment><USER33> Call it whatever you want, but everyone knows what "SQL string concatenation" is referring to wrt injection. I don't think a finer point is necessary.

</comment></comment></comment></comment><comment><USER44> I'm mentioned in the article. I had nearly the exact same experience as the author from a different side of the planet -- and we even overlapped on i18n/l10n issues. I actually raised some of these issues in a blog/Reddit post from a rewrite I did in 2016, where this was one of the biggest pain-points (back when native code was cryptic but legal). After that thread was closed without real answers or a way to reply, I stopped participating in any meaningful way to the community and did all side projects in something else. I've been afraid to even ask the community for any sort of assistance because of the hostility I've encountered for suggesting something was wrong or incomplete. You can see in the authors constant preapologies in the article that he's really afraid of the tact chosen for this so he doesn't get any flack to put him in even worse standings with community; this is absurd, and it's the reason it needed to be aired out in a long blog post after bottling frustrations.

I've switched jobs since, but we've discussed migrating from Elm to PureScript for the last like year without having a big enough reason to pull the trigger, but maybe this would be a good time since it seems a lot of people are frustrated in the community and I've had to come up with a few too many 'clever' solutions to get around limitations.

I think Elm is the best playground to learn functional programming, but I wouldn't recommend it to anyone for anything other than a learning opportunity or a narrowly-scoped weekend SPA project.

</comment><comment><USER45> When I researched elm a few years ago, I pretty much came to the same conclusions that the author came about the hard way.

1\. The native / non-native split and coming hard deprecation of native, although makes sense from a 'code purity of the ecosystem' perspective, will ultimately be a huge hindrance in practice.

2\. Elm specifically puts it's author as the single point of failure, decision making and design, because he wants to make sure the language features are designed right by sacrificing development multithreading.

3\. Because of the 2 decisions above, forces elm to effectively be a research / toy language, who's ideas we benefit from the ideas showing up in other languages. Such as elm's error messages probably inspiring rust and swift to improve their error messages. You can't rely on elm as a business.

4\. Elm might of been better off not using the browser as it's runtime environment in the end because of the above 3 issues and how bad javascript is and went straight for a flutter or squeak style of implementation setup, which doesn't cause as many 'temptations of native' kinds of issues.

</comment><comment><USER33> These posts (and HN comments) really make me wonder if adopters of fringe languages are always going to be thin-skinned developers who get emotional when they realize they won't be part of the language's design decisions. That "On Whose Authority" rant about Clojure complains about the exact same things. And I'll refer to Rich Hickey's response: [https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au...](https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_authority/do1olag/).

Elm in particular has this weird problem where there are vocal people in the community who you can count on to drape a wet, accusatory blanket over every discussion, and you wonder why they can't just find another language that they do like. Sometimes you need to leave the theater so other people can enjoy the show.

Also what are these languages yall are using where you're part of steering committee level decisions?

This blog post is full of the usual suspect complaints, like being annoyed that a language can use features like custom operators but they can't in their user lib even though most people would agree that user packages shouldn't be able to invent yet more custom operators. It's such a weird jealousy for a point to be "but core libs can do it, why not me? :(". Well, simple: think of the rest of us who don't want every user lib to define its own custom operators. But the complainer here gets hung up on what seems like an ego / entitlement issue.

<comment><USER46> > most people would agree that user packages shouldn't be able to invent yet > more custom operators

I'm actually curious why; I have yet to see people actually abuse operators outside of C++, and those were _in the standard library_ …

<comment><USER47> This can be a problem in Haskell, where you can find a library using some operator like +>>* that you haven't seen before, imported from one of its 30 odd globally addressed modules, which may just be re-exporting other modules.

Hoogle/google rarely help with such operators, so finding any documentation is often an exercise in frustration, scanning through library after library for one declaration.

<comment><USER48> How does Hoogle not help with such operators? Hoogle can search over all packages in the Stackage package set and can also be installed locally to look over all the dependencies of your project.

</comment></comment></comment></comment><comment><USER49> I fully agree with everything listed in this article. One point he alluded to (by mentioning the "friendly" exclamation marks) but didn't fully address is the Elm community's bizarre and infuriating language policing.

You can't say the word "guys" in the Slack channel, or a bot will come and correct you, and tell you to say "folks" instead. And from then on, you'll notice the core team all use the word "folks" incessantly in their writing, it's like some weird cult. You'll notice it from the quotes of Evan and Richard in this article.

The forbidden JavaScript FFI is called either "kernel modules" or "native code" despite it being neither. They also claim it's an "implementation detail" or "flaw" despite the fact that it's obviously not.

There are more examples. If you go against any of these rules then you're ostracized.

I quit using Elm because of this problem above all else. I recognize the need to have respectful rules for conversation but having a dialect of newspeak that you're forced to use is just too ridiculous.

<comment><USER50> > You can't say the word "guys" in the Slack channel, or a bot will come and > correct you, and tell you to say "folks" instead.

Being asked to use inclusive language is a weird thing to complain about, especially as the very first example you give.

> And from then on, you'll notice the core team all use the word "folks" > incessantly in their writing, it's like some weird cult.

I use "folks" and other non-gendered language by my own choice. It's a habit I developed after self-reflection. Am I in a cult?

<comment><USER51> >Being asked to use inclusive language is a weird thing to complain about

that is, if you consider the word 'guys' as gender bound and inclusive.

Female friends with myself in attendance are often referred to as 'Guys' by waitresses, waiters, and serving staff nearly anywhere I've gone. A former roommate who worked as a server at a restaurant used the word non-inclusively with the same meaning as 'Folks'.

So, first get people to believe the word 'Guy' is inclusive.

It's not.

It's originally synonymous with 'Fellow'[0], which is also from non-inclusive origins meaning colleague, even if 'Fellow' was attached to males in the 50s and 60s common American English.

>I use "folks" and other non-gendered language by my own choice. It's a habit I developed after self-reflection. Am I in a cult?

Good. That's a great choice of habit. I commend you.

Now, please, reconsider 'Guys', it's not as bad as the (current) common tongue might paint it.

[0]: [https://www.washingtonpost.com/news/volokh- conspiracy/wp/201...](https://www.washingtonpost.com/news/volokh- conspiracy/wp/2015/05/14/the-origin-of-the-word-guy/)

<comment><USER52> > >Being asked to use inclusive language is a weird thing to

> that is, if you consider the word 'guys' as gender bound and inclusive.

I think you might be overlooking another possibility. The same reasoning applies if you believe that SOME OF YOUR AUDIENCE considers the word "guys" to be gender-bound. If that is true, then a reasonable person might decide that for the sake of that audience it might be polite to use a different term even if that reasonable person doesn't ascribe any gender to the term.

</comment></comment></comment></comment><comment><USER53> I've been working in Elm for a few years, and I feel like I can answer some of the questions.

0.19 introduced a new restriction on Native code (javascript), previously you could compile kernel code in your own projects, now you can't. You've never been able to publish a package using native code to the package site (only packages under the elm or elm-explorations github namespace can).

If you feel strongly about it there are ways around it, forking the compiler, or giving your project a fake "elm/whatever" name so that the compiler will build it, there is also a set of shell scripts on github that allows you to get around the restrictions. I've used it before to make some tooling to track virtual-dom performance.

The biggest miss in the post in my view is not looking more at using Custom Elements for the internationalization needs. Having a custom element where you pass in a posix time and have it formatted using the Intl APIs is very possible, and it also allows you to wrap up the interface between Elm and JS in a nice, type-safe way.

The 0.19 upgrade was fairly large, but manageable. Our app was around 70k LOC when we upgraded from 0.18 to 0.19, the upgrade was fairly smooth, and it hugely improved our build times. I had actually forked the 0.18 compiler to improve build times, full builds took around 2 minutes, and incremental builds around 45 seconds. In 0.19 full builds take 4 seconds and incremental builds less than a second.

I share in some of his experiences as well, I have had posts deleted on the Elm Discourse page for mentioning a way for someone to run a fork of a core package to get a fix. I stopped working on a private package manager for Elm after someone described an existing solution as a hostile attack on Elm.

Overall the benefits of Elm still outweigh the downsides for me, no other language I have used has made development a joy like Elm has, refactoring is honestly fun, change whatever you want, follow the compiler errors, and at the end everything works again. Packages are generally high quality and work, an Elm package that hasn't received any updates in a year probably isn't abandoned, it's finished. Coming back to code I haven't worked on in a while is easy, the type system has my back, and most Elm code looks similar due to using the elm architecture and elm-format.

<comment><USER43> Side-note: "kernel" code is bad naming for JS modules.

<comment><USER54> I would say the name is fine in terms of the Elm runtime. This is not about JS modules, but about calling the JS API of the browser and also managing some state there.

</comment></comment></comment><comment><USER55> This came at an awkward time. I just bought Richard Feldman's book "Elm in Action" a few days ago and was working through the first 2 chapters. This has made me reconsider my intention use Elm in my startup.

Having features randomly fail on me and having to rewrite an entire library in elm vs calling out to js means less time creating features that matter to my customers! I was drawn to elm as a way of spending less time debugging my own code in production. Part of that overall strategy means pulling in tested, working code whether it's also elm or js.

Some of what I see here could easily relegate elm to being a toy language; a damn shame considering how good it is as far as strongly typed functional languages to js go.

<comment><USER56> > _This has made me reconsider my intention use Elm in my startup._

Choose Boring Technology [http://boringtechnology.club/](http://boringtechnology.club/)

Seriously, don't use up your startup's innovation tokens on some guy's hobby programming language.

<comment><USER55> I used elixir for the backend and its paid off in dividends. That said, I had a year of experience working with it so it was boring technology for me at that point.

<comment><USER33> I use Elm on two large websites in production with users.

Elm helps me come back to these projects after months and, in two cases, a whole year, and get immediate work done without recredentializing in the whole codebase (which I have to do with my React projects to a greater extent).

You definitely can't be a fragile developer to use Elm, and I think the small community size makes people feel like others are obligated to listen to their opinions. Meanwhile they don't expect this from an ecosystem like React because they know nobody is going to listen to them, the ecosystem is just too big with too many people with hobby horses.

I've patched the compiler one two occasions for the 0.19 release. One was to allow me my Debug.crash calls. Elm is updated so slowly that it's trivial to maintain your own patch. Though I ultimately factored out my two patches.

While TFA makes some good points, just like I can enumerate the downsides of all technology that I use, a large bulk of it is just emotional catharsis. And I think this kind of exodus is a good thing. A lot of the people who supposedly leave stick around like a turd circling the drain just to give their aggressive two cents any time something negative can be said about Elm. I've always felt that to be most tiring of all. Kind of like the people who show up in every Typescript-related thread to say how static typing is for lazy developers and what not.

<comment> dorian-graph > One was to allow me my Debug.crash calls.

This innocent line has a lot behind it, and probably a lot of PTSD for Elm developers.

The Elm compiler has a --debug flag that would compile with a useful debugging window. It was fundamentally broken for how long? A year?

There were many, many posts about it in that time, several community forks etc. There was little comment on this from Evan or the inner circle.

The debug flag being broken, and seemingly ignored, is a horribly beautiful example of the blog post. Imagine having effectively the only debug tool broken for your main programming language

</comment></comment></comment></comment></comment><comment><USER57> I knew nothing about Elm or Luke or Evan before this, but I'm always curious about social relationships in the developer community. That said, I read Luke's article, then watched Evan's video "What is Success?" then I went back and read a couple more of Luke's articles. I am reminded of "Scala War Stories with Paul Phillips," which to me is kind of a classic of the genre of a great developer with huge passion and incredible work ethic almost driven to a nervous breakdown. [https://www.youtube.com/watch?v=v1wrWQcqLpo](https://www.youtube.com/watch?v=v1wrWQcqLpo) I was really impressed with Evan's thought process. I liked his thoughts and feelings about design simplicity and getting it right. I was also really impressed with Luke. He has a practical bent I appreciate and was really excited about his i18n solution, rightly so...and then the clash... I'm really sad about this. There are no winners here. No one is wrong. It's a loss all around. I'm sorry.

</comment><comment><USER58> Evan is brilliant, Elm even more so.

There are trade offs that they are making that I totally understand. There is one way to do things. There is one path to fix things. Everything works one way and works incredibly well.

But those trade offs come at a cost. It is very hard to take Elm into production having to put all of your trust in Evan and the few in his company. There are going to be times that your bugs are not considered bugs by the core team. There are going to be times when your required features are considered harmful to Elm by the core team. Other projects allow you the freedom to work around those sorts of things. Elm has tightened things so this is very hard to do. Elm has made huge wins by doing that. But it makes Elm in production a much harder sell.

I love Elm I want to use it production. But I don't want to have to front to my manager trying to explain we can't do X because I picked a technology that met my needs as a developer but not failed to meet the needs of the business.

Evan has every right to build Elm as he sees fit but it's painful to sit here as a dev and see something so perfect yet have to go for something so terrible for commercial considerations.

<comment> chase-sequence I cannot understand how one could call something "so perfect" if it cannot be feasibly considered for use in production. How can something perfect come with so many drawbacks and warnings?

<comment><USER58> Please forgive my hyperbole.

Elm achieves simplicity and reliability by having it's entire eco system locked down.

But it turns out the same things that make it a brilliant developer experience make it unusable in production.

I suspect I can and might use it in production but if I do I will be putting a lot of trust in one guy. No one else can really take over.

</comment></comment></comment><comment><USER59> I'm not sure why this hasn't been mentioned by anyone: If you're unhappy with Elm's constraints the obvious solution is to switch to PureScript (purescript.org). It's basically are more powerful Elm like language with a great FFI and absolutely no constraints how to work with JavaScript. There are also a lot of compatibility packages to provide functions and workflows from the Elm ecosystem.

<comment><USER60> The learning curve to PureScript is way higher than Elm. Is that not that obvious?

<comment><USER61> Do you think it is harder to learn than Ocaml/ReasonML though?

I think there is a good free introductory book [1], a welcoming community [2], the language and ecosystem are quite stable nowadays and there's good tooling (now that there's the Spago package manager).

[1] [https://leanpub.com/purescript/read](https://leanpub.com/purescript/read) [2] [https://discourse.purescript.org/](https://discourse.purescript.org/)

<comment><USER62> It's definitely harder. I have been doing O'caml for about 20 years now, and we have probably one of the largest Elm apps out there. I looked at Purescript, especially because it also compiles to other languages (C++, BEAM) but the learning curve is a bit steep.

</comment></comment></comment></comment><comment><USER63> Original author of the elm-firebase ( [https://github.com/pairshaped/elm- firebase](https://github.com/pairshaped/elm-firebase) ) here. While I think Elm certainly has some rough patches in both their aggressively PC community and the immaturity of the language (still many breaking changes, not 1.x, etc.), it's not that awful. I was told that elm-firebase was basically a waste, and don't use native modules, so I stopped development. I didn't need to make a big stink, and write a huge blog post on why I'm leaving Elm and how the community is toxic.

If the author needs to leave the community, then do it, but no one needs to leave a community with so much drama.

<comment><USER64> That's what many people (myself included) have done. Unfortunately by not sharing our experiences, others will have to learn things the hard way.

If Evan is entitled to run Elm however he wants, Luke is entitled to post whatever criticism he wants on his own blog.

If nobody ever speaks up, do you think things will actually ever get better?

<comment><USER63> To be clear, I don't have a problem with Luke posting his experience, but there's a difference between reporting the news and reporting your feelings.

I think about half that article could be deleted, and it would still hold content of "why I'm leaving," but without building this huge drama oriented narrative.

<comment> dorian-graph As much as we can pretend that feelings aren't involved in software engineering, it will never be true, especially when relationships is the currency

</comment></comment></comment></comment><comment><USER65> The last time I looked at Elm was about ~4 years and this attitude was already showing. We hesitated building our business front-end in Elm at the time and had a general bad feeling about its future considering the various interactions we had seen. Seeing this article makes me pretty glad I didn't invest time in Elm.

<comment><USER66> Same. We founded on Haskell but had some need to more front-end oriented code. Can say Elm was never considered because I was hearing this weird stuff back in 2016--not to mention it would just make hiring even harder. Can't trust tooling that will be capricious.

<comment><USER67> What did you settle on, considering you were otherwise Haskell focused?

<comment><USER66> Typescript. We try not to be type/pl theory fanatics. Choose your tools well. Haskell is great since the core of our product is an interpreter/compiler with multiple stages. But I don't wanna use it everywhere.

Personally I'd be using JS (or TS) + jQuery. Almost no dependencies, but a lot more manual. No one would be happy on the team if we did this of course. And it can be impractical

</comment></comment></comment></comment><comment><USER68> Elm has a bus-factor of 1. [https://github.com/elm/compiler/graphs/contributors](https://github.com/elm/compiler/graphs/contributors)

I feel quite uncomfortable hitching my wagon to a single developer who owes me nothing.

<comment><USER40> Why are the most recent commits about implementing an endpoint to receive donations for his foundation? Why would you want that in a compiler?

<comment><USER68> I took a look at Elm a couple of years ago and while I was intrigued I simply couldn't consider using Elm in any serious endeavor. Not because it isn't capable, but because the risk of it dying if/when Evan stops working on it (for any myriad of reasons.) Yes someone could fork it, but that doesn't ensure it would continue to be well-supported.

Remember RethinkDB? When they shut down, the software was open-sourced to much fan-fare, but for all intents and purposes it appears progress has come to a screeching halt: [https://github.com/rethinkdb/rethinkdb/graphs/contributors](https://github.com/rethinkdb/rethinkdb/graphs/contributors)

Elm is unfit for any commercial software project IMO as long as it remains a one-man show. I (like everyone else) have limited amount of time to learn new tech, and despite Elm's technical merits - it's not worth sinking any time/effort into it at this time when other more viable options exist.

</comment></comment></comment><comment><USER69> Has anyone started a full fork of the compiler and ecosystem?

It seems like the size of the pool of the "Elm disaffected" is large enough by now that a fork of the entire project might be worthwhile.

I imagine there are a lot of software engineers (like me) who at one time used Elm, but lost interest under the leadership of the core team.

<comment><USER70> I think people have already taken the good parts of Elm and implemented those ideas in other frameworks. Redux was inspired by the Elm, for example. I personally like using React, Redux, and Typescript. It's nowhere near the purity of Elm, but it's good enough.

</comment></comment><comment><USER71> Long, but I think reasoning was explained very nicely without it reading like an attack on anyone in particular. I would love to read a nice response to this, but personally I will not be looking to use Elm anytime in the future.

<comment><USER72> Agreed. I initially groaned at the length, but I think it was necessary to make his case. This isn't the first time I've heard complaints about Elm leadership like this. And I especially appreciated his nuanced take on open- source projects and entitlement.

I tend to place organizations on a spectrum from supportive to controlling. It always is a mix, of course. But open source especially should skew supportive, and this seems like just the opposite.

</comment></comment><comment> ar-nelson I haven't used Elm, so I have no horse in this race. But I feel like I've been hearing these stories for a while, that it started out as an interesting and useful language but kept having features removed in new versions. Since it's open-source, and apparently there are existing projects in older versions of Elm that would effectively be held hostage by these feature removals, I'm amazed there hasn't been a (well-known) fork yet.

Has anyone considered making a compatible fork of Elm?

<comment><USER73> They could call it pine.

<comment><USER74> Or even Mutt.

<comment><USER74> Well I guess that downvoter doesn't know much about email history.

</comment></comment></comment></comment><comment><USER26> I gave up on Elm years ago. It's kind of funny, I paid for the Elm in Action book that was partially written like 6 or 7 years ago. I got an email last week that it's finally finished. It's hilarious that the book has taken this long, probably because they had to rewrite it every release.

<comment><USER75> Mostly the same for me, but a "mere" 4 years ago. Absurd.

</comment></comment><comment><USER76> I've used Elm on a few projects - most recently oldfashioned.tech - and it's a lovely language. I read this article expecting the word 'ethical' to eventually point to something and it never did.

The author wanted a different language, shouted at a bunch of people for not agreeing with him, those people correctly wrote him off as a productive member of the community, and then he wrote a long blog post about how he can't see their side of the argument.

Indeed, he should use a language that aligns with his preferences. Extrapolating from his experience into this right vs. wrong narrative doesn't actually work.

Even after his explicitly acknowledged troll-like behavior, he didn't get some expletive-laden response from the project maintainers. He wasn't banned from the repos. At no point does he substantiate the idea of the leadership style being 'threatening.'

On the other hand, there are plenty of communities with actual threatening, abusive behavior in plain view, that everyone's aware of. There are plenty of communities that "well actually" every forum post instead of being helpful. Elm isn't one of those.

</comment><comment><USER77> I've invested a lot of time in Elm about two-to-three years ago, the two main things was elm-ui [1] and elm-github-install [2]. At the time elm-ui was impossible to build without "native code" so I used it and built elm-github- install to make it work.

Suffice to say, I've run into the exact same issues as the author. Had they allowed me to contribute in a meaningful way Elm now would have a nice UI library and probably a much nicer package website which I've developed as well [3] (no longer running, but I've turned maintenance mode off for a few days so you can take a look).

I stopped using and contributing to Elm when 0.19 came out. If you are interested how much effort I put in just check the Elm related repositories in my Github profile [4].

After that I missed the developer experience and I created Mint [5], so in the end some of knowledge I gathered during that time have been put to good use :)

I just can't understand how they could ignore all the work I've put in, if someone would invest that much time and effort into Mint (or any open source project of mine) I would welcome it and or at least start a dialog on how we could integrate their work into the language.

Anyway, I thought I share my Elm story with you (although probably a bit late :))

Cheers

[1] [https://github.com/gdotdesign/elm-ui](https://github.com/gdotdesign/elm- ui)

[2] [https://github.com/gdotdesign/elm-github- install](https://github.com/gdotdesign/elm-github-install)

[3] [http://elm-directory.herokuapp.com/](http://elm-directory.herokuapp.com/) [https://github.com/gdotdesign/elm- directory](https://github.com/gdotdesign/elm-directory)

[4] [https://github.com/gdotdesign?tab=repositories&q=elm-&type=s...](https://github.com/gdotdesign?tab=repositories&q=elm-&type=source&language=)

[5] [https://www.mint-lang.com/](https://www.mint-lang.com/) [https://github.com/mint-lang/mint](https://github.com/mint-lang/mint)

<comment><USER78> Mint looks cool!

Maybe this is answered somewhere, but what would you say is the differentiator between Mint and Svelte? Many of the design choices seem similar. I am in the position of starting a new hobby project soon myself and currently Svelte is the one I have landed on.

Thank you for your efforts.

<comment><USER77> Thanks :)

Mint has what Svelte doesn't:

\- consistent language with a good type system \- at its base it is a functional language \- styling is built in - [https://www.mint- lang.com/guide/reference/components/styling...](https://www.mint- lang.com/guide/reference/components/styling-elements) \- routing is built in - [https://www.mint-lang.com/guide/reference/routing](https://www.mint- lang.com/guide/reference/routing) \- language constructs for error handling \- language constructs for asynchronous tasks \- compiles to Preact so the build output is small \- easy JavaScript interopability

Svelte has what Mint doesn't:

\- it is basically JavaScript compiler \- different syntax for template (HTML) vs code \- code is just mostly JavaScript and can use NPM packages (I think) \- have their own runtime without virtual DOM \- transitions and animations are built in \- reactive by default (without the need for language constructs)

I haven't really played around with Svelte though so I might be a bit biased. I suggest that you try both a see what you like more.

Let me know if I can help with that :)

<comment><USER78> Thanks for the great answer, very comprehensive. I will try out Mint :)

</comment></comment></comment></comment><comment><USER79> Well done to the author for the level of self awareness in this post. It's hard when faced with frustrating situations to remain calm and critique usefully rather than emotionally, but this was mostly well done.

I hope more engineers can learn to be this self aware. I know I'm working on it.

</comment><comment><USER80> Somewhat tangential to the valid arguments here, it _is_ possible to work around the Elm 0.19 restrictions:

[https://vllmrt.net/spam/subverting- elm.html](https://vllmrt.net/spam/subverting-elm.html)

[https://github.com/robx/shelm](https://github.com/robx/shelm)

</comment><comment><USER81> Wow, this is pretty damning. The author seems fairly level headed and the criticisms feel well reasoned. I've played around with elm a little bit, but this really puts a damper on my desire to dive in further. Hopefully the core team takes some of this criticism on board.

<comment><USER82> I've definitely found Elm worth playing around with - it's a really beautifully designed language with some really cool library design thrown in that I wish more people would learn from. That said I'd _really_ recommend steering clear of it for important stuff due to the issues described in this article.

</comment></comment><comment><USER83> As someone who's been watching Elm since 0.18 and writing Elm since 0.19, I've heard similar stories to this in the past.

Elm is a great language for building frontend apps, I feel far more confident and enjoy writing code in Elm than I ever did in JavaScript / TypeScript. It also feels like Elm is becoming a little more stable and hopefully the big breaking changes of the past aren't going to be as severe moving forward.

I do wish Evan and the core team were a touch more vocal and transparent about future plans and responsive to bugs / issues. There's a balance to strike here and it doesn't feel like we've hit the sweet spot yet.

I'll still keep on writing Elm, as it still brings me happiness. I just hope issues like this don't have an overwhelming impact of the growth of the community.

</comment><comment><USER84> When I decided to commit my project to Elm, back in 2017, I have seen all those writings on the wall. Basically I am buying in someone's whim. One caveat is that I can stop following his whim, freeze source code that I need and carry on my development with out needing or caring about future releases, ie, I do the dreadful fork.

I work alone so I choose my tech destiny.

But when you look at the guy at which will you are submitting to, and can't but say he is the everything I want from a COMPILER MASTER. He have designed clean and well working language and ecosystem around it.

This is the ecosystem where you are not afraid that one of library's dependencies might install crypto miner or steal your user data.

You are sure with like 99.99999....% that you won't have errors in runtime.

And language is simple, my wife started writing it, you only need to know to structure the code and all the frontend power is to you.

Ad hominem - also Evan is soft spoken guy that cares about his life's work, and sharing it with others.

Ad hominem on my side - I am sick of ALGOL languages. After 12 years of proffesional work with many different languages, touching JS or anything related gave me head aches, such inherently stupid and inefficient ways of building systems, from syntax to /ways of doing things/ and making sure they are /allright/.

Luke may have different ambitions than me, I wanted to build reliable systems that brought me money, for me, after 3 years of Elm, I am happy as I can be.

I build new features with confidence and speed. It took me 3 days of work to switch to 0.19. I have deleted big chunks of JS that I though were necessary in order for my app to work. But I was wrong, there were pure way to do it. That was rewarding mental exercise for me, after which I had cleaner code, and customers noticed performance improvements.

Can language /be better/? Yes.

Is Elm at the point where think it desperately needs some improvement, because of which my work is blocked or stalled? No. It wasn't like that since 0.19.

Luke is off and rude in this post at least. He is considered about the posture of OSS not the real benefits of it. Why Luke didn't came up with big blog post about the features he would like to see in Elm? Much more constructive than bitching about it.

<comment> dorian-graph > Luke is off and rude in this post at least.

I found him humble, self-aware, forgiving, and kind

> Why Luke didn't came up with big blog post about the features he would like > to see in Elm? Much more constructive than bitching about it.

I think you may have missed one of, if not the, fundamental point of the post. Even if he did (which he did at times), it would've been pointless.

<comment><USER84> Please, if you find a link to constuctive Luke's criticism, please post it, I am willing to change my mind.

</comment></comment></comment><comment><USER85> I used Elm in 0.18. I actively campaigned for its use. After 0.19, I actively campaign against it.

Back when I chose Elm, ReasonML and ReasonReact was not around. That is what I would choose instead now. I am currently stuck with an Elm 0.18 app that I'll need to convert to React or bucklescript-tea.

Elm's leadership and as a result the community around it is super arrogant and toxic.

</comment><comment><USER34> As a casual user of Elm it was interesting for me to read from someone who knows more about its development process. Unfortunately the author is frustrated by the process. And that frustration resonates with me. I've personally run up against these end-of-discussion comments that do not address the points that were raised in the thread.

Obviously, the developers of Elm can choose their development style. And those who can't live with that style can fork or fuck off. Still it is sad to see people sore from conflict. The author has a lot of investment in Elm, otherwise they wouldn't have written this. When I need to decide on my involvement in Elm, I will consider how conflicts are resolved.

I understand the purism of Elm, and I know it is part of why I like the language. I accept it takes unpopular decisions to keep it "pure". On the other hand, when I see people break off over limitations that the Elm project places on its users, but not on themselves (one of the main points of that article) I do get a sad feeling. What kind of relationship is this where you trust yourself with compiler features you don't allow other people to handle? Words like patronizing, controlling, and self-serving come to mind. They may have the best of intentions and my protection in mind, but I prefer the privilege to know I can shoot both my feet if I need to.

</comment><comment><USER86> I have a hypothesis that people treat open source a little like the way that some managers and product managers treat software engineers — as dispensable, as people that shouldn't have authority or control, as people that don't know what the best is for the product. Unfortunately this isn't true. Empathetic makers — the ones that are most successful — are often deeply in touch with (a) needs of customers and (b) know what they are capable of offering. Unfortunately, what individuals offer is often not thought of as a gift (in both the open source world and in business), but rather as a given. This orientation is harmful to the human spirit, but unfortunately we have grown used to it in our world of seemingly endless commodities.

</comment><comment><USER87> Having maintained an open source project for a while I relate to a lot of the problems brought up here.

It's really really hard to create a contribution system that works well when there is a large set of users, a large set of contributors, _and_ a tricky design space. It's tempting to become authoritarian, especially when the design space is complex and you've thought about it longer than anyone else. Inclusion is a shit ton of work, and a lot of it feels non-technical and boring to most people.

It's tempting to throw away compatibility and ask users to just deal with it. No project is perfect at this, but infrastructure stuff has a much higher bar for this than most other projects. That makes everything else that much harder.

Most tech culture undervalues management a lot, especially in open source. But open source should be valuing it _more_ , because the problems are so much harder than in a small co-located one-company team -- communication is lower bandwidth and higher stakes, there's no way to manage other people's schedules, there's differing goals and incentives, and on and on.

</comment><comment><USER88> I find it fascinating that the author is leaving one fringe language with a small community for another fringe language with a small community- in this case Bucklescript.

I've never found the productivity benefits of these JS alternatives worth the risk and cost. There is an understandable desire to move away from the messy reality of JS and it's browser friends, I get it. Having written many thousands of lines of CoffeeScript, experiments with ClojureScript and Elm, I see the appeal.

But you can easily find yourself stranded. Following the herd is important if you want to hire and maintain projects for the long term.

<comment><USER33> The upsides make more sense if your Webpack/JS tool chain was growing out of hand. For example, once you take on Typescript, you take on quite a bit of idiosyncrasies. And your Webpack config may grow pretty large over time. We have some hacks in our Webpack config just to avoid some thing like double ESLint/TS evaluation. And it all can start to feel quite precarious. We even found bugs in Webpack's circular dependency plugin.

Meanwhile, Elm does a lot of this right out of the box. There's a point where you may be easily reducing complexity and idiosyncrasies by using a tool like Elm.

<comment><USER88> I agree that opionated frameworks can reduce complexity. I was Rails for a very long time.

But moving to a new language that you can't hire for seems like an extreme reaction to "our config is complex". One good thing about a mainline technology like TS is that thinga get attention. Manual config today may be supported feature in the future.

<comment><USER89> Isn't the real risk, in moving to a fringe frontend framework, not just that you can't hire, but that you run into some roadblock you just can't get around? That you have some abstraction leak or messy interactions with JS?

<comment><USER88> This too. And then you're only as good as the interoperability your platform is providing.

</comment></comment></comment></comment></comment><comment><USER90> If the post is accurate in the Technical Limitations section I wouldn't touch Elm with a 10 foot pole.

</comment><comment><USER91> Maybe am mistaken but isn't a language that hasn't reached version 1 by its nature supposed to have breaking changes. It is expected that while you can use the language for your projects there is no guarantee that new additions won't break your code so you use it at your own risk unless Elm uses a different versioning system.

</comment><comment><USER92> Holy Moly. Congrats on such a concise critique; I expect it's hard to spend so much work on the thing you're _leaving_.

<comment><USER21> I'll second this. I've read many "why I'm leaving <x>" posts and regardless of the degree someone might agree/disagree with the contents, it's a very fair article. That's difficult to pull off, I'd say.

</comment></comment><comment><USER93> Really well reasoned parting letter.

Hoping he'll fare better doing Reason instead. I've tried and haven't had much luck selling it to our local Powers That Be but I understand it's a bit of a nerdy, tough sale.

<comment><USER94> Started following Luke back when he was doing a lot of Django work. He's not the type to do things "just cuz". Most of his work is well thought out and very reasoned. Big fan of the guy honestly.

</comment></comment><comment><USER95> What I learned from this article:

All Elm developers are equal, but some are more equal than others.

<comment><USER75> And that distinction seems to be very, very clear.

</comment></comment><comment><USER96> I really like Elm. I don't use it now for some of the reasons pointed in the article but I like the lessons it taught me.

It shows how you can do a lot of things with functional/reactive programming.

Building an app in Elm can be frustrating but it can teach a lot of concepts.

</comment><comment><USER97> I will forever be grateful to Elm, for introducing me to Functional programming. And the helpful community. But a lot of things could've been handled differently in that community. e.g if Elm had been made sort of the route that ReasonML is trying to go i.e a functional ML wrapper around JS. with full inter-op without the message passing madness.

</comment><comment><USER98> After reading that I'm fairly clear in my mind that Elm is something I will avoid if possible. The author seems extremely credible to me and several of the quotes entirely damning. For example, the one where the core team / leader ended a communication by saying that they weren't interested in hearing alternative views but that they did want feedback on whether their communication was clear. I cannot imagine that behind those words lie people I would want to work with.

</comment><comment><USER99> The closest I've been to using elm is elmish.

As a completely random internet user evaluating what proglangs to look at next, I'm staying far, far away from elm itself.

</comment><comment><USER100> This is a ton of emotionally charged verbiage about community interactions here, but at any point does this person say what they were using Elm to do? That seems like a pretty important point. Is this somebody who was just using the language recreationally, for their own amusement? And if so, did they have some expectation for the language community to be a source of (online) social interactions and connections with people?

Because if so, that really changes the significance of the accusations, in the sense that it makes them almost meaningless. "I wanted Elm to be my new life and my new friends and I wanted to shape it myself as a personal milestone but that stuff didn't happen and now I'm mad and I'm leaving" is a heck of a lot less meaningful to me than, "this language doesn't work well for the problems I'm trying to solve, and the maintainers aren't interested in adapting it to my problem domain, so I'm going to move on to some other language for this thing I'm working on".

I really don't care if someone is pissed that a language development community didn't make someone feel like they belonged to a social club or otherwise interacted with him in a way that satisfied some void inside of him. But if there was some actual purpose to his language noodling, as opposed to being purely recreational, it would be infinitely more interesting to know about how it fell short of the purpose, why the language fell short, why the maintainers didn't want to evolve it in that direction, and what language the author is moving to for their project that does a better job, and why they chose that language. That's meaningful. Anything related to whether or not they felt listened to or if they felt like they were on the inside or the outside is just utterly meaningless, it's like when people complain about news articles that don't have anonymous comment sections.

I realize that to a lot of people, the recreational community aspects of open source development are literally the only thing they care about. But I also realize that to some of those people, they don't understand that this is not the primary purpose of hardly any of the projects they care about, language projects probably least of all. Open source maintainers are not obligated to anybody to create a fun community for recreational users, with a well-lined pathway to becoming a recreational core developer. But that is clearly all that this person cared about, hence all of the emotional stuff which I just don't get. I'm not saying it's invalid, I just don't personally relate to that perspective at all.

<comment><USER101> I mean, he goes into some detail about the issue: he wants to be able to use an internationalisation library, but the best option is in javascript, and these libraries are very hard to write because i18n is really hard with a bunch of edge cases. He also gives evidence that some commercial apps using Elm _really_ need this functionality. He wrote bindings so it could be used in Elm, it worked well, but the core team were not interested in his solution, seemed to misunderstand the problem, and will not allow anyone else to solve it without an outright fork (which the core team act extremely hostile towards).

</comment></comment><comment><USER102> Elm wasn't the right language/community for this author and that's ok, not everything is for everyone. I use and love elm as something to write my side projects in. It has a zen like appeal for many reasons:

\- No runtime exceptions in practice, so you are developing against the compiler and almost never need to manually test what you're writing

\- Very opinionated about how to do most things. There's usually just one good library to solve a problem and it solves it in a particular way. What you lose in the process of trying to solve your problem in a way that's not optimal for you, you gain in not having to search for the optimal solution.

\- Little politics or debate about the language itself. This does make it like a cult, that's a fair comparison. Doesn't hurt my enjoyment of it though :)

\- Tooling is pretty good, with helpful linters, stylers and plugins for vs code, vim and so on that the relatively small community has standardized on.

\- Very active community on their Slack, I get considerable help on all problems from syntax to architectural at all hours of the day from certain tireless people on there. I do my part to help as well, I try to help the ultra-newbies now that I'm not one anymore.

I think the type of engineers who "think big" and want to do very ambitious things that would require them to have input on the direction of the language will not be happy in Elm, so I'm never surprised by the posts like this that are quite frequent. HN is especially full of these type so be cautious if this note is applicable. I also don't think I would recommend Elm as the solution to my 2k+ engineer company even though it's my favorite language. There's just too much at stake at that point to take a chance that the Elm process will screw you. But for small projects, maybe under 50 people? I think it can be a very strong candidate.

<comment><USER103> May I ask, how are you doing i10n?

<comment><USER104> We do internationalization at Cambiatus. Here's our front end code so you can take a look: [https://github.com/cambiatus/frontend](https://github.com/cambiatus/frontend)

<comment><USER103> Thanks. That's pretty cool. But I guess I misspoke, what I meant to ask was how are they doing stuff like this: [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/Intl)

I.e., date/time formatting, number formatting, and so on.

</comment></comment></comment></comment><comment><USER105> This mirrors my experience quite perfectly.

To add another aspect: The over-management of GitHub issues is, in my experience, borderline pathological.

On dozens of occasions (no exaggeration), I've experienced the following:

\- I notice some bug, or some missing functionality.

\- After dozens of searches I finally find a relevant Github issue. It's difficult to find because it's closed, in a project with a different, former name to the current version of the package, and part of a now-defunct GH organisation.

\- The only comment on the issue was Evan saying the issue is being folded into some meta issue bundling "issues concerning <some broad concept>". He closes the issue and adds a line into the meta issue.

\- Any discussion of individual items on the meta-issue is blocked

\- Work on that collection of issues is not going to happen "right now" because "it's so much more efficient to work on sets of related issues".

\- 14 months or so later, some work is done on <general concept>. The issue is closed (& locked)

\- My original issue obviously persists

Evan seems to consider open issues as accusations or personal failures, or otherwise I can't understand why this is happening. When some recent version broke the existing support for WebSockets, the issue was immediately closed (making it, again, invisible to people experiencing this problem and searching with default options).

The most constant output of Elm leadership are long-winded essays explaining how, specifically, you're stupid. You don't get to use WebSockets. We could merge this patch fixing the problem, but anyone could do that. It's just code, after all, and "Code is Easy" ([https://www.youtube.com/watch?v=DSjbTC- hvqQ](https://www.youtube.com/watch?v=DSjbTC-hvqQ)). Have you heard about XY problems? It's a great concept that neatly explains why _you_ are the problem, not us.

I _really liked_ Elm. I would (have) loved to see it succeed. I fully understand that small, young projects come with limitations, that it may take a long time to fix some issue, that backward-compatibility may be broken, etc. Not once have I complained about some issue, Elm or otherwise, not being fixed fast enough. And on the few occasions where I witnessed such a sense of entitlement, I called them out on it.

But the defensiveness of Elm Core to whatever they perceive as hostility has somehow led directly from "benevolent dictator" to this weird kiddy version of Stalinism, where everyone is always upbeat, and "constructive", and prefacing even totally valid questions with five paragraphs of Dear-Leader praise and caveats about probably just being really stupid, lest they trigger the benevolent ego.

I'm just really happy I never used Elm for work projects. I imagine trying to get something fixed when it really matters is a lot like getting ventilators to blue states these days.

</comment><comment><USER106> Seems like two different discussions going on here, on the one hand you have core language design such as not having typeclasses, and it's fair to say it's the core team's prerogative to organise these decisions as they want. On the other hand there's no good argument for intentionally restricting language features from certain users, it's not in anyone's interest. I am a big fan of safe languages that use a formalism to stop you _accidentally_ modifying shared state or hitting a runtime error but why should the designers care about me making a bad architectural design, i.e. including some JavaScript modules in an elm package? If I misuse it and write a bad application that's my problem, you can't protect bad developers from themselves because they'll just use other tools. If I publish a library with JavaScript, okay show a warning to the user, have red scary text on the package description page if you want. But let the users decide how they want to build their applications. The argument that this would block a clear path to WASM is bogus, they've already shown that breaking tons of libraries doesn't bother them.

</comment><comment><USER107> I've used Elm professionally for about a year, having done full rewrites of both a bloated React/Redux SPA and a map data visualizer with complex JS interop using ports to Leaflet, AWS Cognito, etc. Luke Plant's blog post doesn't at all reflect my experiences with Elm or my feelings about the core team.

For those not privy to the Elm tea, a brief primer: this blog post is primarily concerning a months-old issue regarding the removal of the ability to use native modules, which are effectively patches to the Elm runtime[1] which circumvent the core features of the language that provide its greatest strengths: a genuinely helpful compiler and ironclad runtime guarantees (still have yet to encounter a production runtime error that wasn't on the JavaScript side of things!) This "feature" (used loosely) was largely undocumented, always verboten from distribution in user packages, and never intended as anything more than a stopgap measure in extremely rare cases.[2] It was /officially/ not a core language feature intended for widespread usage, and consistently advised against by the Elm team. The removal of native modules was spoken about publicly months before the breaking upgrade. It came as no surprise to me. As an engineer who tries really hard to be responsible, I do not build software which relies on features which are advertised as 'do not use unless absolutely necessary' and are soon-to-be deprecated unless I'm willing to accept the inherent risk of doing so.

The core Elm team was, in my opinion, extremely communicative, well-reasoned, and thoughtful in this change and in others, despite the inconvenience to a small subset of people. For each feature discussed in Luke's post, there is an accompanying Discourse thread[3], discussion on Google groups, Github gists[4], etc., that carefully lays out the reasoning, and carefully consider the scope of a change (in the instance of the removal of custom operators, the Elm team analyzed the package ecosystem and determined less than 5% of packages were affected)[4].

I won't cover the moral arguments around the obligations of open source maintainers as this has been covered ad nauseam with the Clojure and Rust fiascos of a similar sort - though I personally believe maintainers don't owe anyone anything, and I try to treat all free software graciously, as a precious gift, lucky to receive it at all. I will say that Elm's somewhat slow, closed BDFL-ish governance is well-documented as well[5, 6], available to all who seek to understand the Elm development process and decide for themselves if this is an ecosystem to hitch their wagon to. Of course the Elm maintainers get to patch their own runtime with native modules, because they are implementing core parts of the language, it's practically tautological. That users living in userland cannot do it is not unfair; it's a language design feature. What Luke seems to see as a stifling of an open community by the closure of issues and deletion of posts on the Discourse is often basic organizational maintenance to handle redundancies. Conversations around these issues have happened for months and in some cases years, and decisions have been made. They may not be to everyone's tastes. That should be just fine! If someone went to Famous Amos Cookies on Discourse, Slack, their mailing list, and opened a Github issue and PR suggesting this genius idea they just had, it's so good, wait for it - an oatmeal cookie without raisins! - I hope they would clean it up, close the issue, delete my posts, etc., for their own sanity. Not to mention that the opening to Luke's opus here is an admission of his own rudeness to the Elm team on most of these fora. Of course the relationship with maintainers will be strained with this kind of behavior.

There are critiques of Elm, to be sure. The pace of releases is somewhat slow, custom operators might be nice for 3rd party parsing libraries, it might be cool to have a PR merged in to get that fuzzy feeling only OSS contributors get. But you cannot reasonably argue that Elm's team has been unfair, discriminatory, uncommunicative, or arrogant (pathos, so much pathos here!). I don't generally post comments anywhere, but articles like this are irresponsible and damaging not just to the well-being of maintainers who are being generous with their time trying to make something with great care, but to people (like many top level commenters here) who might have tried Elm but won't due to an inside baseball post from a spurned developer. It makes me actually sad, like want-to-cry sad.

[1] [https://newfivefour.com/elm-lang-basic-native- module.html](https://newfivefour.com/elm-lang-basic-native-module.html) (any somewhat experienced Elm developer will get nervous looking at this trivial example and immediately see what might break)

[2] [https://groups.google.com/forum/#!msg/elm- dev/1JW6wknkDIo/H9...](https://groups.google.com/forum/#!msg/elm- dev/1JW6wknkDIo/H9ZnS71BCAAJ) (2015!)

[3] [https://discourse.elm-lang.org/t/native-code- in-0-19/826](https://discourse.elm-lang.org/t/native-code-in-0-19/826)

[4] [https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc7...](https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc76b1)

[5] [https://www.youtube.com/watch?v=o_4EX4dPppA](https://www.youtube.com/watch?v=o_4EX4dPppA)

[6] [https://github.com/elm/projects/blob/master/roadmap.md](https://github.com/elm/projects/blob/master/roadmap.md)

<comment><USER108> I have been using elm at work (in prod) for about three years, my team and I have rewritten a hard to maintain 50kloc+ angular application to elm. The rewrite started with elm 0.18 and was finished with 0.19.

We started using elm extensively about a year before 0.19 was released and it was very clear to us from the start that even though it's possible to use native modules, it's a feature that should not be used and will not be supported in the future.

The experience we have had with elm and it's community have been nothing but great.

If we had stumbled upon a blog post/ thread like this when figuring out how to proceed, I'm not sure we would have given elm enough thought and tested it out properly. This makes me really sad as well.

</comment></comment><comment><USER32> I've just realised that by the understanding of "Open Source" assumed by Luke and by many of the commenters here:

\- Firefox isn't Open Source.

\- Lots of other things often held up as shining examples of Open Source are not Open Source.

...because they are worked on by people or teams who decide their own design goals and roadmap, and while you can contribute and talk about the project, many users feel the project moves on without catering to their needs or remaining compatible over time.

Firefox is an interesting example, not only because it's a poster child for Open Source, but because it evolved from Netscape Navigator's source release and is associated with events when the "Open Source" term was being coined.

</comment><comment><USER109> I don't use Elm. But I have watched several of the founder's talks about different subjects. That is to say, I have a half decent idea as to what the 'native modules' issue means. I think Luke's issue is that under the newest release Elm is requiring that no code contain any 'raw' JS or it won't compile. It seems like this was an option prior to the current version so is this basically like if the Rust team said as of the new release no code, other than that code coming from the Rust team may use 'unsafe'?

— This is an honest question I've been holding in all afternoon, and seeing this still on the front page, I just decided to ask.

<comment><USER110> > issue is that under the newest release Elm is requiring that no code contain > any 'raw' JS or it won't compile. It seems like this was an option prior to > the current version so is this basically like if the Rust team said as of > the new release no code, other than that code coming from the Rust team may > use 'unsafe'?

Yes, the problem is similar. It can be considered worse, because in safe Rust you can do almost everything, but Elm is much more limited.

You can still use regular JavaScript with ports, but it is more complicated. It is something like a WebSocket channel, where the server is the JavaScript code.

</comment></comment><comment><USER111> I'd be interested to see why the author would be unable to use the ports interface to work with the API of his package.

My understanding about why the core team is being so controlling over the native modules access is that they're trying to prove that each native module is pure, so they can make assumptions and declarations in the compiler that the code produced is pure. By forcing unblessed/unreviewed modules to use the ports interface they can maintain this assumption. Without doing this you lose all of that assumption and your compiler falls apart, if it's based on that assumption.

<comment><USER112> The author gives more specifics in the footnotes, specifically footnote #4 [https://lukeplant.me.uk/blog/posts/why-im-leaving- elm/#id14](https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#id14)

</comment></comment><comment><USER113> I can't believe people are still complaining about something that happened almost 2 years ago for a good reason, or even about Elm not having typeclasses, or worst, for elm-format using 4 spaces, that is pointless. And I personally prefer Elm the way it is, with typeclasses the compilation speed and error messages wouldn't be the way it is now. There is already Purescript for those who need typeclasses and better js ffi, no need to follow the same path. In the next few years Elm will have everything we need as pure elm, and libs with great quality.

</comment><comment><USER114> This is a very emotional piece. While a lot of his points are true from some perspective, they seem to come from an expectation that Elm should be treated the same as enterprise languages or frameworks, whose ultimate goal is to "get traction and adoption" as success measure.

I have used Elm in a hobby project, a multiplayer web game, which I have been developing over 4 years now. Elm has been a complete joy. New features and refactors are done incredibly fast AND safe. I believe this is due to Elm's restrictions letting no unsafe code "in".

</comment><comment><USER115> Is it just me or does the Elm development style resemble that of Go?

<comment><USER23> It's not just you. There's definitely a similar "we know how to do everything better, which means differently" vibe here, and a similar penchant for rewriting everything to minimize library dependencies outside of the ecosystem.

But with Go, at least it's the community as a whole making the decision to be like that - people might shy away from cgo, for example, but it's a convention, not a hard limitation. And if you do decide to use Go in your app, you still get to choose how much or little of it there will be.

With Elm, it seems that there isn't any community consensus along these lines, or even a community in the same sense (i.e. that can establish a consensus that would be meaningful). It's practically a religion - you get the rules delivered to you on stone tablets, and you're either all in or all out. Except in this religion, there are new stone tablets every couple of years.

It might be an overly uncharitable comparison, but I can't help but remember [https://wiki.lspace.org/mediawiki/Abominations_Unto_Nuggan](https://wiki.lspace.org/mediawiki/Abominations_Unto_Nuggan). Especially "Abomination 6543: Umbrellas or any other Devices that shield the wearer from the Blessings of Nature", in the context of native/kernel code.

</comment></comment><comment><USER116> Besides being much more elegant, Elm's tooling is very limited when compared to JavaScript and React. When working with the js+react+redux combo, you have access to specialized browser extensions that allow exploring the application structure and events. It's sad because the language precedes Redux, but the centralization from its owner made it lose the boat. The fact that the Elm blog has a new post only once a year does not help, either.

</comment><comment><USER117> This sort of thing is why I stopped open sourcing my work (I had several successful open source projects a decade ago). I realized that it was the responsibility of an open source maintainer to put the community first, but I was only interested in strictly pursuing my own interests. Neither side was wrong, I just realized I wasn't cut out to be a maintainer. Maybe Evan should also consider if he's cut out for the job.

</comment><comment><USER118> When a technology wraps over another technology with its own opinions - doesn't it always end up bad?

Especially when the wrapper decides to take away the escape hatches, locking people into its opinions without considering genuinely valid exemptions.

I wonder how so many truly bright minds, bought into this philosophy, despite knowing this was coming. I guess the promise of Elm was just far too convincing.

</comment><comment><USER119> I loved the Elm architecture even though I left it behind a couple of years ago because it developed into an explosion of files with a fairly large project.

I hardly interacted with the community (although I think I remember that slack bot correcting people for using 'guys') but the architecture is both conceptually simple and great and should be emulated.

</comment><comment><USER120> No offense to anyone here contributing to Elm, but the project sounds like it's a dumpster fire based on the linker post.

</comment><comment><USER121> If it all ends up generating Javascript, why don't people learn to write good Javascript.

Rather than compound problems with unnecessary incompetence and calling it functional and typed. The only thing typed I discovered is undefined incompetence from Elm to C++.

There is always an excuse to complicate problems when you are incompetent and invent useless languages.

</comment><comment><USER122> Although the particulars are unique, this seems to be another problem stemming from what I like to call "Having Your Open Source and Eating It Too Syndrome". Namely, it seems to me that the authors don't actually want an Open Source project (or perhaps more accurately a Production-Ready Open Source Project). They may certainly want many of the advantages that Open Source brings, but are upset by what I think are honestly completely predictable consequences from not living up to the, regrettably for lack of a better word, "responsibilities" of Production Open Source. I say regrettably because I don't want to get into an argument about what is actually "owed" \-- I agree no one entered any contract or whatever. All I'm saying is if you put in the work to convince someone that something is production-ready, and convinced them to stake their livelihood on your project, then it shouldn't be surprising that they are upset when you prioritize abstract principles or decisions over their ability to ship. Again, I'm not implying you should be forced to have a process or do what they say, just don't be surprised when your users get upset, and then on top of that accuse them of "entitlement".

There's a lot of convenient, and perhaps subconscious, confusion of terminology in technology. For example, people can point to the fact that a project isn't 1.0 yet and argue "well you should have known anything goes pre-1.0". But Linux was amazingly solid prior to 1.0, and even the term "Beta" has been watered down by Google's infamous insistence of using the term for ages on their software. I'm not saying you have to agree with the watering down of technical meaning, but you _should_ understand the unfortunate reality that a lot of this is mixed signaling. For example, a common one is "It's beta but we use it in production and it works great!", which if you break it down is kind of a used-car-salesman technique. It's saying "I've created plausible deniability for myself so that I owe you nothing, but the final thought I'm going to leave you with is an emotionally manipulative statement that wink wink it's really ready to go".

Similarly, if you have a fancy landing page telling people why your product is better than other production-ready products, for example Elm compares itself against Angular, React, and Ember, then you are strongly implying you are a peer. So even though the words "production-ready" don't appear on the page, there is a strong implication here. There's certainly no asterisk anywhere saying "pre-shipping numbers", something that game trailers will even do. Again, I don't think this is intentionally deceitful, I think it's supremely easy to accidentally run into this sort of messaging. But you should absolutely be mindful of this and work against this.

Luckily, this is all fairly avoidable if you're willing to take some simple steps. For example, just say "this is a toy project" or at least "We absolutely do not recommend this for production", or even "the primary purpose of this project is for researching ideas that interest me". That can completely avoid any miscommunication and sets expectations up correctly, and furthermore puts you 100% in the right in the event that someone ends up relying on your code... But no one wants to do that because it hurts adoption! This is what I mean by wanting to "Having Your Open Source and Eating It Too". You want to portray an amazing product that does everything well AND is a happy community, while reserving the right to treat it like a side project whenever you want.

</comment><comment><USER123> Elm gets taken out behind the woodshed again on hacker news. Remind me not to open source software.

</comment><comment><USER124> Just bought the book _Elm in Action_. If people are so frustrated about the leadership, but still say it is a great language, it definitely is worth checking it out.

</comment><comment><USER125> Haskell will accept you !

[https://haskell-miso.org/](https://haskell-miso.org/)

</comment><comment><USER126> Wow I never knew how much I loved typescript until reading this. Never had a blog post worth of complaints, at worst just cast to 'any', write a comment to recheck after the next update, and clock out at 5. And maybe pray for forgiveness from God for my code having side effects if I'm feeling guilty.

</comment><comment><USER127> I literally just started learning Elm this week and then I find there's all this drama and baggage to consider.

It's seems like 0.18 to 0.19 was a divisive upgrade for the community. I feel like a lot of good languages or frameworks go through this existential crisis at some point. There was Python 2 to 3, or Angular 1 to 2, Node vs IO, etc.. I think Vue narrowly avoided it on it way towards 3.0 (maybe remains to be seen). I remember when Rails community split when Yehuda Katz got frustrated with DHH and made Merb, and then they merged back together for Rails 3.

It seems like open source has a love/hate relationship with the benevolent dictatorship model.

</comment><comment><USER128> [https://github.com/dmjio/miso](https://github.com/dmjio/miso)

"""

Miso was written exactly for Haskell enthusiasts who want the simplicity of an Elm interface without sacrificing too much performance. The benefits I'd say are thus:

• Type sharing. A lot of web dev becomes boilerplate -- serializing and transferring state is a large part of the work of web dev. Type sharing ensures correct-by-construction serialization between server / client amidst any changes to your business logic data types, allows you to focus on your apps core offerings as opposed to minutia.

• Rich ecosystem. The Haskell ecosystem has many great libraries that compile w/o any problems on the frontend.

• Concurrency. Programming with threads and synchronization primitives is now first class in the browser.

• Extensibility. Compared to Elm's ports feature, the GHCJS FFI is a much simpler way to interface with third-party libs. Also, Haskell supports typeclasses, and Generic programming, a rich lens library, etc.

• Community involvement. You'll be working directly at the intersection of a lot of interesting developments in GHC, specifically around cross compilation, syntax, lenses. Any new advancements to GHC has an impact on your frontend code. Also, many PhDs use, love and contribute to Miso. These people tend to be very smart, empathetic and intellectually curious as opposed to dogmatic and contentious that can be found in the software engineering industry at large today.

• Nix, a one-tool-to-rule them all for dev, build, and deploy. While not easy, deterministic builds are the future and help one to sleep at night (I've found). It can be used solely for personal dev, or for an entire organization, and anything in between.

• Virtual DOM. If your Haskell web framework does not handle the tedious task of DOM manipulation for you, you have been failed as a library consumer IMO. Miso has a very well-tested, simple recursive micro virtual DOM diffing library that can exist standalone and can detect regressions in performance via a benchmark suite.

• Simplicity. Unlike many other ivory tower libraries in Haskell, Miso maintains a simple interface. Many different common abstractions were explored in the early stages of development (free monads, FRP, etc.) and found lacking, unnecessary or replaceable by a simpler solution without sacrificing features. Miso does not attempt to hide behind complex type-level abstractions and blame end-users for their lack of understanding. As opposed to a top-down approach that shoe-horns an abstraction into an environment where it does not belong, Miso takes a bottom-up approach to fully understand its environment, the browser, it's APIs, the DOM and its short-comings and provide a simple commonly-used abstraction to the end-user that can scale to large applications. This also makes it easier for newcomers to Haskell to get up and running quickly.

• Industry adoption. Several companies are using miso in production for various things in their company, from full product to internal tools / data visualization.

• Isomorphic. Due to the rose tree structure of both the DOM and HTML, pre- rendering increases load-time and overall UX along with correct SEO.

"""

^ from the author of Miso

</comment><comment><USER128> [https://github.com/dmjio/miso](https://github.com/dmjio/miso)

Miso was written exactly for Haskell enthusiasts who want the simplicity of an Elm interface without sacrificing too much performance. The benefits I'd say are thus:

• Type sharing (A lot of web dev becomes boilerplate -- serializing and transferring state is a large part of the work of web dev. Type sharing ensures correct-by-construction serialization between server / client amidst any changes to your business logic data types, allows you to focus on your apps core offerings as opposed to minutia).

• Rich ecosystem (the Haskell ecosystem has many great libraries that compile w/o any problems on the frontend).

• Concurrency (Programming with threads and synchronization primitives is now first class in the browser)

• Extensibility. (Compared to Elm's ports feature, the GHCJS FFI is a much simpler way to interface with third-party libs. Also, Haskell supports typeclasses, and Generic programming, a rich lens library, etc.)

• Community involvement (You'll be working directly at the intersection of a lot of interesting developments in GHC, specifically around cross compilation, syntax, lenses. Any new advancements to GHC has an impact on your frontend code. Also, many PhDs use, love and contribute to Miso. These people tend to be very smart, empathetic and intellectually curious as opposed to dogmatic and contentious that can be found in the software engineering industry at large today).

• Nix, a one-tool-to-rule them all for dev, build, and deploy. While not easy, deterministic builds are the future and help one to sleep at night (I've found). It can be used solely for personal dev, or for an entire organization, and anything in between.

• Virtual DOM. (If your Haskell web framework does not handle the tedious task of DOM manipulation for you, you have been failed as a library consumer IMO. Miso has a very well-tested, simple recursive micro virtual DOM diffing library that can exist standalone and can detect regressions in performance via a benchmark suite).

• Simplicity. (Unlike many other ivory tower libraries in Haskell, Miso maintains a simple interface. Many different common abstractions were explored in the early stages of development (free monads, FRP, etc.) and found lacking, unnecessary or replaceable by a simpler solution without sacrificing features. Miso does not attempt to hide behind complex type-level abstractions and blame end-users for their lack of understanding. As opposed to a top-down approach that shoe-horns an abstraction into an environment where it does not belong, Miso takes a bottom-up approach to fully understand its environment, the browser, it's APIs, the DOM and its short-comings and provide a simple commonly-used abstraction to the end-user that can scale to large applications. This also makes it easier for newcomers to Haskell to get up and running quickly).

• Industry adoption. (Several companies are using miso in production for various things in their company, from full product to internal tools / data visualization).

• Isomorphic. Due to the rose tree structure of both the DOM and HTML, pre- rendering increases load-time and overall UX along with correct SEO.

</comment><comment><USER129> That was a long, long one.</comment>