Hacker News new | past | comments | ask | show | jobs | submit login
Why I’m Leaving Elm (lukeplant.me.uk)
732 points by neillyons 58 days ago | hide | past | web | favorite | 431 comments



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


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.


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


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.


>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?


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


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


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.


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.


I don't doubt it. FWIW, I was really impressed with Elm the language.

But I don't see how their current messaging can possibly be working for Elm's benefit. It feels like the PL equivalent of a politician who refuses to shake hands or take selfies. I don't think it requires Elm or Evan to make any technical compromises just to be a little less off-putting.


I have met both Evan and Richard, having been a member of the SF Elm Meetup group. My experiences have shown me that they are both deeply empathetic individuals who are very methodical in their approach to improving the language.

Evan spends every Meetup exclusively focused on attendees who've no it's very little experience with the language, basically giving them a personal guided tour. In these sessions here is very kind and patient - and a skilled teacher.

Richard is friendly as well and does a great job communicating the vendors of Elm's design and how best to take advantage of it. He is also a senior practitioner who writes Elm on a daily basis.

NoRedInk is truly powered by Elm, and that has helped them hire very easily despite not having tons of cash to throw around (they make education software).

So at the end of the day, I've come to view them as true believers in a very particular vision for the language. It is compelling, especially when walked through it by Evan. But they have a lot personally on that vision.

In many ways, they view themselves as taking the long slow road to what will be the "UI language of the future". They want many people to try the language and see the benefits of immutability, purity, and declarative UI. They want people to follow their lead and use those principles in using Elm in their projects.

But in their eyes, Elm is not done. They have no interest in people coming in and suggesting that Elm should be something else. At times, that's lead to some rash behavior that looks bad. But as practical as Elm is for many projects it is not Pragmatic. And that turns people off.

And if it turns you off, I'd leave Elm off your list of choices for a language in your production projects...for now.

It is yet to be seen if Evan's vision will succeed in it's goal of making functional, declarative, strongly typed UI programming "mainstream". But he's proven that he is committed to that vision regardless of a large host of workaday engineers asking him to compromise in some way.

Maybe some day, custom operators come back. Maybe some day there will be type classes. But I can guarantee that day won't come until the vision is complete and you see Elm 1.0

PS: I fully empathize with the people turned off by this approach by the way, but I can't help but truly appreciate someone doggedly standing firm on their design principles and seeing it though despite it costing them an opportunity at widespread fame. I have no long term contact with the Elm core team, and no projects using Elm currently. Maybe when I see 1.0 :-)


> But in their eyes, Elm is not done

I think this is one of the major themes of all the 'Elm dramas' that we have been reading and hearing about. Elm core team should stop recommending it as a stable platform that people can try out (which Elm clearly is not).


I've personally never seem them say "the language is done, you can expect no breaking changes". Hence the fact that it is v0.19


I have read several times that they do not consider the language stable. Yet they repeatedly advertise it as «production-ready» [1,2], which is contradictory at best.

[1] https://discourse.elm-lang.org/t/two-experiences-with-elm/91...

[2] https://github.com/gdotdesign/elm-github-install/issues/62#i...


> the language is done, you can expect no breaking changes

Well ... I don't use Elm in production. But, I'm sure there are people out there who got gaslighted because of this ill-conceived move, and they can better explain about 'production readiness' story that was weaved around Elm.

> Hence the fact that it is v0.19

I also don't understand how can a minor version 0.18 -> 0.19 completly break backwards compatibility even if it is not stable. Well may be it's just Elm. They should have atleast thrown a `deprecated` warning and maintain backwards compatibilty till the next major version.


It's in line with semantic versioning, point 4 [1]:

> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

1. https://semver.org/#semantic-versioning-specification-semver


> Major version zero (0.y.z) is for initial development

> Anything MAY change at any time.

Thank you for clarification. So, now it begs the question how did Elm team persuaded people to try out their language in production if it is still in initial development and anything MAY change at any time ...


> 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 just watched that segment. He argued his position with a satirical touch. A summary of his position that characterizes him as "mocking critics" is inaccurate, imo.


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.


I'm not much into web development professionally, but it's something I learn and use a bit as both a hobby and for personal projects. I looked at Elm a while back (maybe two years ago, but I'm not sure exactly). I decided against it after I ran into some issues related to language instability and old documentation. I dug a little further and it appeared to be how the Elm project was run, so I stayed away.

On your second point

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

I totally agree. But I also think it's good when others point out the weaknesses in the project publicly, to prevent people from wasting time or having to deal with certain personalities. As long as it's true and done in a professional manner, an important part of open source is harsh public criticism.


For a hobbyist like me, Elm bounced around far too quickly that every time I returned to my side project it was incompatible. Worse, a library I would be using wouldn’t have made the upgrade so... that seemed OK in the first year or so but after a while you need some stability. The author is 100% right about how Elm’s package manager and repository are the only ones available and they can be really lacking sometimes.


I think there’s also a third category, which is “I’m interested in Elm / have dabbled in it but all this puts me off ever using it for anything serious”.

If the comments in this thread aren’t ringing red alarm bells for the Elm leadership I don’t know what will, frankly.


Elm is an experimental research language. It's fun to learn and make little toy projects in and that's fine No one is getting rich off of Elm having professional users.

It showcases an interesting architecture and has lessons for Haskell-style languages in how to make compiler error messages that aren't hideous


Yes, Elm is eventually turn out to be inspiration for other languages and go nowhere itself. As a professional Elm developer makes me sad.


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


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


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.


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) and it's still getting the occasional bug fix: 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.


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.


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.


Semver is fine it just slightly obscures the fact that sometimes language designers give up and abandon the language but don't want to give up the branding


There's also the third type of comment: the outright, raging denials from Elm enthusiasts.

If anything turns me off a programming language, it's the righteous fury a community rains down upon its naysayers.


Out of curiosity, what keeps you from pinning elm version in your projects unless you are a library developer?


Not the OP, but I can think of a few reasons:

  * security patches
  * browser compatibility changes
  * build tooling compatibility (unless you pin that too, but that never works for long)


HN doesn't support markdown for lists.


Yes I know, that's why I indented it


Please don't, it makes it annoying/hard to read on mobile( it doesn't wrap)


I'll take that under advisement.


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


> This criticism is spot on; it is exactly what I observed in late 2018, early 2019 as well.

These issues were obvious much earlier than that. I looked into Elm and was excited about it initially, in either late 2013 or early 2014. Then I looked into the history of some of the design decisions that baffled me (such as lack of type classes) and concluded the project was poorly conceived and led. The leadership didn't respect the opinions or capability of its end users.


> The leadership didn't respect the opinions or capability of its end users

This was the major sticking point for me when it came to Elm. I invested a lot of time into Elm and even published a few packages. Many things contributed to my giving up Elm, but the final straw for me was when the core team removed some userland APIs under the guise of "we can't trust developers not to use these to write bad code". Myself and several others tried to convince Evan to reverse this decision, to no avail.


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.


Here's the relevant section from the article for this comment.

https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#why-d...


Hasn't package.elm-lang.org gone down a couple of times last year alone, which stopped people from installing/updating packages locally?


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

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


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.

That is acknowledged in the article. But the fact is that you can BE open source without doing the things that make open source WORK.

[...] 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.

Why should unhappy Elm users do this instead of going to a language+environment that they don't have to fork to get something usable for them?

Leaving, even leaving with a long essay like this one, requires a lot less energy and commitment. And being in an environment where you can benefit from the future work of others is part of what makes open source work.


If you're using/contributing to a open source project that is famous for it's non-community development and BDFL leadership style, it should come as no surprise when that continues.

The call for "If you're not happy you should fork the code" comes because this is a explicit expectation of the Elm core team and Evan.

What does "open source work" really mean? Open Source talks strictly about the licensing and distribution of the code itself, not the community and everything around. It feels like everyone are having two conversations at the same time. Open source as we currently know it, is just about the code. Open communities (or whatever you want to call it) is a separate discussion, and not needed to "make open source work" as you just have to license your code in a specific way to be open source.

Then we can discuss what makes open communities around open source code work, but I think that's a separate thread.


If you're using/contributing to a open source project that is famous for it's non-community development and BDFL leadership style, it should come as no surprise when that continues.

That's pretty much the central thesis of the article. With detail and examples on exactly what the leadership problem is and why it causes challenges for users.

The call for "If you're not happy you should fork the code" comes because this is a explicit expectation of the Elm core team and Evan.

And yet any attempt to do so is described by them as knifing Elm in the back.

What does "open source work" really mean? Open Source talks strictly about the licensing and distribution of the code itself, not the community and everything around.

What I mean by "work" is that it leads to successful projects. By a variety of metrics for success.

It feels like everyone are having two conversations at the same time. Open source as we currently know it, is just about the code. Open communities (or whatever you want to call it) is a separate discussion, and not needed to "make open source work" as you just have to license your code in a specific way to be open source.

Then we can discuss what makes open communities around open source code work, but I think that's a separate thread.

You have it exactly backwards.

You are right that "what is open source" is a different discussion from "what makes open communities around open source work". But this is the appropriate place for the second conversation. And more specifically for discussion of what it is that the Elm leadership is doing that leads to failure, and what it is that users should or shouldn't do given that Elm is being so badly lead.


> the leadership problem

It's only a problem for the ones who misunderstand the model. It's not a problem, it's by design. It's explicitly setup so that Evan has the final say in everything.

> What I mean by "work" is that it leads to successful projects. By a variety of metrics for success.

I'm always interested in hearing what metrics people are using for "success", so do please list them so we can be on the same page.

> You have it exactly backwards.

The author is the one using "Open Source" in their article, not "open communities" or "open governance". I understand it can be confusing, but let's not change the meaning of already existing terms.


> And yet any attempt to do so is described by them as knifing Elm in the back.

Do you have an opinion on open source communities that threaten and seek vengeance against their own forks?


No


>> the leadership problem

> It's only a problem for the ones who misunderstand the model. It's not a problem, it's by design. It's explicitly setup so that Evan has the final say in everything.

The fact that they intended to do a stupid thing does not stop it from being a stupid thing.

The core development team of Elm is an echo chamber of smart people who only listen to each other. When they are working on problems in their area of shared expertise, they should be very effective. But when they step out of their shared expertise they are predictably both ineffective and have no way to discover their mistake.

In this case they know little about i18n and therefore are unable to take feedback from people who know how it works. And there is no way to get them to see their mistake. These faults, left unchecked, will undo all that they hope to accomplish.

> > What I mean by "work" is that it leads to successful projects. By a variety of metrics for success.

> I'm always interested in hearing what metrics people are using for "success", so do please list them so we can be on the same page.

That is a fair question. For me success means, "I can use this to solve my problem, and be able to trust that this is something that will be maintainable in the future."

There are different routes to being maintainable. The smaller it is and closer to my own expertise, the more I can be confident that I can maintain it myself. If it is complex and far from my expertise, I won't.

Maintaining a language someone else built is not exactly the kind of thing I want to do in maintenance. (This is from experience, not ignorance. At my last $job I did exactly that with an internal language. And that language was much less ambitious than Elm.)

> > You have it exactly backwards.

> The author is the one using "Open Source" in their article, not "open communities" or "open governance". I understand it can be confusing, but let's not change the meaning of already existing terms.

You are seriously going to let a quibble about terminology prevent you from understanding what the author clearly meant??

Now that you know what I think that the author meant, go back and re-read it to see if you think I am right. If I am, you can see that what I am talking about is on topic.

But since you want to open up the terminology issue, Open Source BEGAN as a marketing term for a particular software development philosophy BEFORE there was a settled definition for what open source software meant. To this point, one of the founding inspirations was http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral.... Furthermore the practices for how Elm is being developed are exactly against that philosophy. (ESR is an idiot in other ways, but that is a discussion for another time.)

That this started as a philosophy and not a mere licensing term is obvious in things like the free software community's response to the phrase. If you want to dive down that rabbit hole, read https://www.gnu.org/philosophy/open-source-misses-the-point..... (Written by the person most directly criticized in ESR's essay. Ironically, also the person who probably did the most to create the foundation that open source built upon.)

So you learned something today. You learned that, from its very inception, there has always been a lot more to the phrase "open source" than just a licensing definition.


> Open Source BEGAN as a marketing term for a particular software development philosophy BEFORE there was a settled definition for what open source software meant. To this point, one of the founding inspirations was http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral.... Furthermore the practices for how Elm is being developed are exactly against that philosophy.

If you're going to bring up the origins of "Open Source", the above is NOT CORRECT.

It began as a marketing term for "Free Software" principles, as it was realised the FSF marketing wasn't convincing people in corporate environments.

From Wikipedia (I think this is accurate):

>> Netscape's act prompted Raymond and others to look into how to bring free software principles and benefits to the commercial-software industry. They concluded that FSF's social activism was not appealing to companies like Netscape, and looked for a way to rebrand the free software movement to emphasize the business potential of the sharing of source code.[35]

Not as a marketing term for Bazaar principles, despite ESR's involvement in both around the same time. Obviously the Bazaar paper added significant inspiration to the movement and to many projects, and informs some people's expectations around Open Source. But I have heard ESR talk about the origins of "Open Source" and it was quite clearly because "Free Software" wasn't getting the message across; the latter was too ethics focused for the corporates.

Btw, you can have Open Source without a Bazaar, and you can have Bazaar-style development without Open Source too (a lot of companies do so without giving it that name).


I'm describing how I experienced it as a young developer at the time. It was a weird combination.

Note in particular that a lot of people who jumped on the open source bandwagon were people who wrote some free software but did NOT want to only write free software. And there was a lot of messaging around social norms for how projects worked, why open source made sense, and how to do well by it.


> Why should unhappy Elm users do this instead of going to a language+environment that they don't have to fork to get something usable for them?

Of course they can do that, but then they are not Elm users, which makes them off-topic to the question of what Elm users should do to move forward as Elm users.

> requires a lot less energy and commitment.

We don't actually know that for sure without looking at the size of someone's Elm code base.

Maybe some users also think that Elm is otherwise fantastic and want to stick with it.

For various reasons, changing tooling is not like changing what shampoo you use, except for some language-hopping butterflies who are experimenting with a new thing every week.


> > Why should unhappy Elm users do this instead of going to a language+environment that they don't have to fork to get something usable for them?

> Of course they can do that, but then they are not Elm users, which makes them off-topic to the question of what Elm users should do to move forward as Elm users.

The topic was someone saying in detail, "Here is why I have chosen not to be an Elm user, and why you shouldn't be either." Which means that the experience of people who are not committed to being Elm users is on topic.

> > requires a lot less energy and commitment.

> We don't actually know that for sure without looking at the size of someone's Elm code base.

Fair enough.

Of course in this case he says that he is walking away from an 8000 line project that can't upgrade to 0.19 because of the native code issue. So we know how much code he is talking about, and also know that a rewrite in a new language is simpler than trying to upgrade.

In this case maintaining a fork certainly exceeds the benefit of the project.

> Maybe some users also think that Elm is otherwise fantastic and want to stick with it.

I am sure that there are.

> For various reasons, changing tooling is not like changing what shampoo you use, except for some language-hopping butterflies who are experimenting with a new thing every week.

No, it is not.

However if you will have to make the change some day, then it is probably better to bite the bullet and accept the pain now rather than adding to it for a future date. And if the leadership problems described continues, it is clear that the Elm community is going to fall apart and any project in Elm will dead end.

Therefore if you are an established Elm user, you should be ready to accept that tooling change pain as a question of when, not if.


> The topic was someone saying in detail, "Here is why I have chosen not to be an Elm user, and why you shouldn't be either."

When someone is saying divisive things, I think it's important to be clear and precise about what they're actually saying. Some of the burden rests on themselves, and some of it rests on the commentators.

And so I think it's important to note here, that I don't think he said the "you shouldn't either" bit. He specifically denies saying it:

> I should also note “Your Mileage May Vary” etc. It would be entirely possible to use Elm and find it adequate for your needs, and therefore never bump into the things I hit very quickly.


Thank you for the correction.

What he actually said was, "I definitely cannot recommend it to anyone else." Which is fairly translated as, "You probably shouldn't either."

But he explicitly didn't say that it was inappropriate for anyone.


I agree with you. The obvious, implicit motivation behind an article like this is to help other users make the same decision. Denying it only constitutes a reinforcing acknowledgement. It's just a rhetorical device. If someone says "I don't mean to be rude, but you're an ass", they in fact mean to be rude.

A good chunk of everything you hear and read revolves around people trying to get others to be like them and do as they do, implicitly so. (Another good chunk is made up of people justifying, explaining and defending themselves.)


> The obvious, implicit motivation behind an article like this is to help other users make the same decision.

This is not obvious to me. Why do you assume the motivation is "to help other users make the same decision" and not "to help other users make the decision that's right for them"? I promise you that some people have sometimes written with that motivation in mind. If any denial is taken as proof of guilt, how do you tell those people apart?


It still makes them not practising elm users. Who have a voice and a say within the community.


Apparently practicing Elm users don't have a voice and say within the community either. That's kind of the whole problem.


Because every single one of these posts is "I like Elm, I don't like Evan('s style of leadership)."

All of these leavers could've maintained that fabled community fork they want with the features they want if they all got together.


It doesn't actually make sense to fork Elm. There are pretty good general-purpose languages already which offer a superset of Elm's (the language) functionality. I think all of them already have Elm-like implementations available as libraries. In fact there's at least one migration tool that helps convert away from Elm: https://github.com/darklang/philip2

Choosing to hard-fork Elm and create lots of internet drama just doesn't make sense compared to moving to one of the above.


And if it worked, they either A) split the userbase in half and make Elm LESS likely to be useful or B) get most of the userbase and make Elm totally irrelevant.

Forking a language isn't like forking a tool. Forking gcc doesn't make C any better or worse. Forking C (if you could) would make the C worse.


True.

But "if they all got together" is waving away the difficulty of getting them all together, cooperating, and working together. Open source projects are a lot more difficult to run than you might expect.


> Open source projects are a lot more difficult to run than you might expect.

Indeed. You pour thousands of hours of work into something and give it to the world for free, only to be met by “give us synchronous IO or we will throw our toys out of the pram!”


That specific example would just be laughable. "I gave you awesome asynchronous I/O; just write the five lines of code around a semaphore if you want it synchronous."


I am sure this moment is coming when somebody creates a fork and gets rid off the artificial hypocritical limitations imposed by the current core team.


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

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.


> 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


> 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?


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


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.


> whatever assumptions he has about open source is not a fantasy

I no way am I going to accept anyone's opinion based on what project they are associated with. If Linus Torvalds says something about open source or free software, I'll read what he says and make my opinion based on what he is saying, not based on that he was the original creator of Linux.

Anything else is just appeal to authority and we would do much better in discussions if we didn't do that.


I don't think the author being a member of Django adds any weight to his arguments.


I find you're being needlessly formalistic here. The author is explaining where they are coming from. What their understanding and expectations in the open-source world are. This helps to understand their position. That initial part was intended (I guess) to make comments like yours redundant. Because that way we can understand what the author means without guessing about their usage of the term.

The article does not require you to share that definition. And haggling over the precise definition of open source does not change their argument one bit. You can say that you use a more restricted definition, and that is it.


> What their understanding and expectations in the open-source world are

Thanks for putting it like that, it's completely true and I agree. Many people have an understanding and expectation of Open Source that not even the definition of Open Source agrees with (https://opensource.org/osd), which is contributing to this problem. That was a bit of the point of my comment.

The article doesn't require anything, but in general, most people see OSI as the organization who stewards a lot of things around in the Open Source world. If people cannot even agree about the definition of Open Source, we're in for a real treat now when companies start to abuse it.

> You can say that you use a more restricted definition, and that is it.

Again, I'm not going by my own vision of Open Source (as the article's author does), I go by the Open Source Initiative's definition of open source, which again, you can read here: https://opensource.org/osd


The OSI definition is useful as a baseline. When people argue over what open-source means, I think they can mostly agree on that definition. On top of it we see frequent arguments over authors' responsibilities and appropriate stewardship.

Looks like I've accepted that it's a broad term used in a lot of contexts. So having somebody give their angle on it before using the term is already pretty good by my standards. But maybe I'm being too liberal here. What parts do you see people expecting in open-source that go against the OSI definition?

(I can't help but note that you and the author write Open Source with caps which does actually suggest there is a specific meaning.)


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

To add to that, the OP's argument seems to hinge on Elm "advertising" itself as open source. I don't see "open source" mentioned on https://elm-lang.org/ or anywhere else. I'm curious where the OP thinks Elm crossed the line from having an open source LICENSE file to "advertising" itself as open source.

If the answer is that an open source LICENSE file counts as "advertising" a project as open source, then why use the inflated language in the blog post? Why not say, "If you [release something with an open source license], there is a common set of assumptions about what that means, some of which are explicit in accepted definitions of the term?"

Also, explicit in which accepted definitions of the term? The OP seems to be stating that without linking to these accepted definitions that would back him up.


Part of the problem here is that he suggested forking (he used the word "patching") the compiler in another project, and one of the core maintainers of Elm jumped into the issue and said it felt like an attack on Elm itself.

That feels a bit silly - why make a project open source if you're going to get upset when someone forks it?


Indeed. Author seems to confuse open source and open access. Or he may like them to be one and the same thing: though luck.


I'm not sure people saying this know that the author is one of the "core developers" of Django. It is safe to assume that his expectation of "open source" is not far-fetched at all.

While you may have a point, language developed with closed process and just the source published in one of the famous code hosting sites need not emphasize on having a "community"[0] if it is not really looking to hear things from the "community".

[0] - https://elm-lang.org/community


In the light of the material you link to, "Why I'm Leaving Elm" does seem to expose a wee bit of hypocrisy there.


The terminology is irrelevant. If you have certain expectations from the open source communities (among the diversity of possibilities that are open source) the narrative of what happened (especially with regards to being considered persona non grata if you fork) are worth knowing about.


You can open a business and yell at customers. Doesn't mean they will stick around or tell others how great your business is.

Good projects die because of bad leadership.


Your suggestion for the problems with this project is "Why don't you just fork it and maintain your own?"


That's right[1]; and the author of "Why I'm leaving Elm" understands this, yet claims that it's not possible somehow because the Elm people are hostile to it, and that's one of the reasons the project supposedly isn't really "open source".

Something seems a bit off in the reasoning. The only reason you can't fork something is that either you don't have all the code, or there is a license problem.

One way not to have all the code is that there is a dependency on specific SaaS server installation, whose source code isn't available. If that's the case with Elm, I missed the coverage of it in the article somehow. I did get the part that the packaging ecosystem depends on a particular server controlled by the Elm project.

1. Well, not a solution for the project, but for some of its unhappy users. The project, as such, perhaps doesn't even feel that it has these problems that require solving.


He doesn't claim it's not possible, he claims that the Elm community will excommunicate you for forking.

I can't think of a language or platform that doesn't have some degree of "soft" forking that maintains communion with the language community. It's common for proprietary reasons (linux kernel, anyone?) as well as experimental reasons (e.g. PyPy). So this is an eyebrow raising claim.


What would they do? I'm not sure there's an actual threat to follow through on. They can't block a forked compiler from, for example, using official packages without close-sourcing their own compiler (to prevent it from bringing in whatever change makes it work again).

At that point, why bother respecting the threat? A forked compiler isn't going to get maintainers? A package depending on the forked compiler isn't going to be maintained? The social cost is possibly something to think about, but if one is set on leaving the community anyways then it's a choice between you choosing to not interact with the community and them (possibly!) choosing to not interact with you.


The community is more valuable than the code, because the community writes the code. So being cut off from the community is a major blow to a fork, and substantially increases their work burden.


Your fork isn't a significant amount of work, unless they've really threaded in the must-be-in-Elm-Kernel check throughout the entire compiler. Versus trying to rewrite your dependency in Elm rather than enabling importing JS, enabling JS is likely to be simpler since the functionality already exists to let Kernel modules do it.


This kind of dismissive response is in line with the examples provided in the OP.


This discussion about whether or not the "Elm community" will be meanies is missing the point and inventing a hypothetical scenario where you get kicked out of some club. Kind of a weird conjecture to me. I guarantee nobody truly cares that you fork Elm. The thing is that generally people who threaten to fork Elm are quite hostile on the Elm forums and subreddit.

If you fork Elm, an already tiny ecosystem, you'll realize that the hard part is building the community, not adding your pet features.

Everyone who has threatened to fork Elm has realized this at the end of the day. It's also why people overlook the lack of their pet features: because ecosystem is far more important.


> I guarantee nobody truly cares that you fork Elm.

One of my coworkers once edited the elm compiler to remove the native code restrictions, and placed it on NPM. Evan emailed him and asked him to take it down.

There may be more to the story that I don't know, but from what I know it sounds like Evan does care.


Did he take it down?


Yes.


> I guarantee nobody truly cares that you fork Elm.

The article cites a comment by one of the elm core maintainers where that maintainer says he is opposed to the author forking Elm, and will consider it an attack on Elm's goals if he does. So I think we can safely discard this conjecture.


I don't understand your argument about ecosystem being far more important. People ceasing use of any of the tools necessarily removes them from the ecosystem and community. They have no reason to care about those things.


But they’re almost certainly moving to a new platform with a community, which is much easier than trying to build one from scratch.


Definitely. At that point, they need to weigh the cost of migrating their existing project to a new platform, or to maintain the patches that will allow the old platform to have the flexibility they need.

It's important to remember that they aren't being removed from the Elm community - they can still use the packages, the compiler will still get updates they could presumably rebase their patches on.


It's still worth knowing that they're being jerks about it, since that falls outside of the social (but obviously not the legal) aspects of open source.


> falls outside of the social (but obviously not the legal) aspects of open source.

Not really, IMO. Forking a project used to be a really aggressive thing to do back before GitHub made it so common among younger waves of developers.

If you go to Evan and say, "Look, I want to use your thing but do it my way." and he says "No, I have a clear vision of what the thing is and it's not that. KTHXBYE." I don't think that's "being a jerk".


On the face of it, my impression is that excommunication, if it happens, is more likely to be caused by the author being burdensome to deal with, than code forking per se.

Of course the author is unlikely to present it that way.

And although I felt the author was moralising in this critique, it may be they are not particularly rude the rest of the time. But even writing a plethora of well-reasoned but difficult to handle posts about what's wrong with your project can be too much.

Well-established languages, platforms and projects such as Linux that have a large labour pool with socially-established patterns of working don't have the same problem, because there's enough labour to deal with it.

Smaller projects just have to turn people away when they become hard work beyond the capacity of the project's core maintainers to handle it, though.

The solution found via FLOSS is to license software so that forking is always possible when a project cannot sustain different visions for the project's direction. This diffuses the tension when people have incompatible needs from the project. Sometimes it comes with drama, particularly if people are competing for attention and trying to persuade others to follow them, but that seems inevitable because of the competition.

It is still understood that forking is permitted and intended to be part of the solution, and the social niceties are that you may be encouraged, perhaps strongly, to go away and run your own fork yourself with your own resources, under a new name/domain/etc. while acknowleging where it came from. Then it's your own job to build a reputation too; it's only fair.

It's very difficult to keep running a project while your competition lingers on the same mailing list, constantly funnelling people towards their fork in the hope of making it more popular. That's a very good reason to "excommunicate" some people, or to forbid some topics such as advertising the other project repeatedly.


> Of course the author is unlikely to present it that way.

I don't really get this accusation in light of the author leading the article with admissions of their own failings in terms of how they communicated with the maintainers of the project?


I'm writing in response to this remark, presented in the parent to my comment:

> he claims that the Elm community will excommunicate you for forking.

If that is correct, what I said is less accusation and more descriptive, and should really say something stronger: "the author hasn't presented it that way."

However if the parent to my comment is mistaken, then I agree that would make that sentence in my response unfairly speculative.


The bit about "excommunication" is very explicitly linked to the author's plan to fork Elm. Now, I don't think "excommunication" is necessarily the correct descriptor. The Elm maintainer who made the threat said that he considered making a fork on "attack" on Elm's goals [1], and that the project would not be greeted with open arms. (Although in the original comment it was a little less clear whether it was the project or the person to whom arms would not be open.) In any case, I think the comment is very clear that the hostility is to the action of forking, irrespective of previous communication problems.

[1]: https://github.com/gdotdesign/elm-github-install/issues/62#i...


I don't see anything about making a fork in the linked GitHub issue.

(The word "fork" appears once elsewhere, in an unrelated context in a different comment.)

The thing about open arms is not about forking (or if it is, it's not obvious to me), and reads to me more like "assuming you are not making your own fork, can you please stop pressuring upstream to accomodate designs which are explicitly against our clearly communicated design goals".

The quote is:

> @spookylukey It's one thing to build tooling around an implementation flaw without knowing the history, but that's all pretty well communicated at this point.

> If you understand the design goals, but don't agree with them, why not channel that in a positive way - e.g. by building something that fits your vision instead of directly working against Elm's design goals?

> As someone who has spent a lot of time collaborating with many others to help Elm achieve its stated design goals, intentionally working against those goals feels to me like an attack on our efforts. We have been really clear about our design goals in this area, and you shouldn't expect a project that works against those goals to be greeted with open arms—especially not from those of us who have been working hard for years to achieve those goals.


The comment immediately before rtfeldman's references patching the compiler for this project, which is an implied necessity if js code is to continue to be used. It's essentially a soft-fork, and that is what rtfeldman is objecting to.


Thanks, fair enough although rtfeldman appears to be responding to spookeylukey about divergent design goals, while it's norpan who is talking about maintaining a locally patched compiler.

I still see no objections to maintaining a fork or local patch from rtfeldman. Just "if you go against our explicit design goals don't expect us to want to merge it upstream for first-class support".

TBH a locally patched compiler sounds like not a huge deal to me. I have lived with locally patched GCCs before :-)

But maybe I'm unusual. I surprised someone, once, when they found some code not working and I suggested they look at their compiler source for the cause. Their response: "Wow, I hadn't ever thought of the compiler as something that might have a bug, let alone read and modify it".


IT was norpan and spookeylukey talking about patching the compiler together, and rtfeldman jumping in with references to PAST discussions of design goals with spookeylukey.


the last thing i want is to get into drama with developers of a project, so if my choices are to give up and leave or fork and face drama, then i'll give up and leave.

how that affects the Open Source status of a project is irrelevant, this is simply not a project that i could use, and thus for all intents and purposes, for me at least, it's a project that can't be forked.


If you fork quietly, you can avoid the drama. Just do your thing and don't respond to anyone (in any forum) who isn't reasonable and civil. Don't start drama, don't feed drama.


if i am happy to just quietly run my private patched version, sure. but that's not the point, because the claim is that for a good Open Source (or Free Software) project, it must be possible to go public, and once you do that, if the original developers are unsympathetic then drama is unavoidable.

there have been hostile forks in projects before, even those that eventually had a good ending. egcs for example.

i was part of such a forked project too. it wasn't meant to be hostile, and the drama was limited to the project leaders, but it happened, and feelings got hurt.

not everyone is willing to take that risk.


That's what forking entails.

It's a bit like Brexit. You don't get to stay in the club.

If there are sufficient people unhappy with Elm but are cohesive enough to push the compiler forward, then why not?


You dont even have to push anything forward. Example Redhat's compilation of code or "forked" by CentOS, who were providing just a little more freedom. We all know how that ended.

Just keep in sync with the main project, and keep the annoying/proprietary stuff out.

> You don't get to stay in the club.

Or you become the club. I think LibreOffice has more club going than Oracle's OOo.


The author’s point is that other languages don’t (typically) kick people out of a club for forking.


I’ve never used Elm, but that’s not how reasonable open source projects work. Red Hat maintains several rather divergent forks of Linux and they’re still in the club. I personally run a fork of Linux that I maintain, and I’m in the club. The only people who attract serious ire from the club are people who distribute out-of-tree modules that play poorly with the rest of the system. Even in that case, no one gets excommunicated, but the upstream kernel makes no particular effort to keep problematic modules working.


The open-source ethos means welcoming the friendly competition that comes from a fork. Look at the grandparent's link for the attitude taken by awk and bash.


gawk and bash aren't UX generating tools

quoting: "And a further consequence of this is that non-English developers and end users are discriminated against, due to the difficulty of formatting numbers and dates in correct ways for non-English locales."

The issue seems to be hypocrisy of the Core team and not that it isn't true open source. Forking a language is suitable only for extraordinarily situations, Elm language might be good but ultimately it's not that extraordinarily good.


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

Open source means you have access to the source in the preferred form for making modifications (and not e.g. dumps of generated code). IMO that should include any design documents that the original maintainers would consult when making modifications themselves.


> 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?


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.


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.


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.


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.


I think Clojure is actually a good example of strict stewardship that works well


I totally agree with this fustration. There seems to be some innate paradox between growing a community and being a BDFL. I think this also expresses is self in our current political environment.


i'm not sure if we need to be bringing politics up in a programming discussion, but hey, that's just my opinion.


This isn't a programming discussion. It's a discussion of the policies around an open source project. It's totally politics, albeit not on a national scale.


If you feel the same way about the Elm project as the author of the article does, you won't be happy with Clojure[script] either. Its community already went through this drama and all the top community contributors(or that at least tried to contribute) left.


I can't speak to Elm, but I'd say the Clojure/Script fiasco wasn't really one sided. Some of the "contributors" not getting their way wasn't like they were wanting to push some amazing improvements. Most of the time, the reason for things not going through is actually disagreement on the impact the change would have to the language, and people complaining about how slowly the discussion around it can happen to drive agreement.

Basically my point is, some people like me are happy that there's a high bar of entry for contributions and that every change is carefully considered, even if sometimes that means changes happens more slowly.

Don't know if that could be true of Elm as well?


if that is the source of the drama for ClojureScript, there is a huge difference between that and the issue with Elm. With Elm 0.19 they have effectively disabled all libraries that use native JavaScript within, unless they are officially approved by the Elm core team, which I understand is no small feat.

Imagine in Clojure if they said "you can't use Java libraries any more. Pure Clojure only from now on" but kept the ability to use Java libraries for the core libraries of the language. -- That is my understanding of the issue with Elm as it currently stands.


Oh, that's a bold move. I doubt this would happen on ClojureScript, in fact, I see the opposite sometimes, some people in the community complain about how Java and JS ruins Clojure/Script and makes everything worse, and why isn't there a native Clojure, where you'd never have to deal with the host. And the core stance tends to be that being hosted is the whole point from the beginning.

I can see the frustration with Elm though, especially that it was enacted as part of a version upgrade. If it was from the start, people would know what to expect, but this seems like a huge backward breaking change. I'd be annoyed as well.

In Clojure/Script, a lot of the tensions are more about what should be a community provided library, and what should be lifted as officially included in core. I see the core team tends to favour most language extensions to be kept as a library. And often when people want changes to the language to be made, the answer is that Clojure/Script is designed to allow user level changes, so whatever you don't like you can change for yourself. Some people still arn't happy about that, they want their ideas to become the standard.

A lot of that stems from it being a Lisp. There's very little of Clojure/Script that actually necessitates changes to the compiler itself. Even the core functionality, most of it is implemented on the basic primitives the compiler gives, so you can happily change and extend almost anything if you disagree with the core team's choices.

Back to Elm, I know personally, I've never been into a language restricted to only one use case, the web. It seems Elm has always wanted to be more of a framework for web development. A very opinionated one. This seems to be a move even more on that direction. Like if Ruby didn't exist, but only Ruby On Rails did. Correct me if I'm wrong here. It could lead to something nice in the long run, but like any framework, the trade off is that when it doesn't have the feature you need, you're stuck.


Regarding

>all the top community contributors left

Please don't pass on misinformation.


Did you ever try Scala.js? I was a huge fan of how fully it was just standard Scala and therefore well-supported by IntelliJ; I've not seen any other compile-to-JS language match that level of IDE experience (but as someone who was already a Scala fan I'm biased).


A bit of an open door maybe, but TypeScript has that level of IDE experience too.


It didn't when I tried it - IntelliJ does support it on some level, but doesn't offer the same depth of automatic refactoring etc. that you get with Scala, to the point that my colleagues generally favoured using VS Code.


What happened that made you hit the wall?


This is one of the biggest reasons why I think ReasonML is better.


Unfortunately ReasonML has its own set of drawbacks which don't make it a drop in replacement. These issues include standard library incompleteness, inconsistent parameter ordering conventions, and poor compiler error messages (compared to Elm).


https://github.com/Checksum/elm-compiler

I just feel like people are right that the core team is not reasonable but at the same time, if there are that many people that like Elm, why not create a total fork?

It might come down to the people that would care enough to do the fork and a server or whatever have already had so much Koolaid that they just accept those negatives. And the other ones that can't accept it don't like it enough anymore to go to the trouble of making a fork.

But to me it seems like the best outcome is a fork that becomes successful.


This perfectly describe the situation. While it is possible to do it yourself in Elm without the update, it is quite hard and cumbersome to do so. It is much easier to make a PR, but Elm core team is purposely relationship and personal-trust based, any random PRs will not get accepted in foreseeable future.


We are using Elm in production for almost a year and I never had a situation where a bug was blocking us. Do you have any example?


> if this is true.

It's as true as it is for Python.


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.


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++ :)


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


Rust is also an example of a language that leans pretty heavily into "familiar C++ syntax as a marketing tool."

Although they did not cave on the Ternary Operator. About which a certain contingent (myself included) is vocally unhappy.


Really growing, so much that it's kinda hard to keep up with


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.


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/


Parts of Firefox are already written in Rust:

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


You shouldn’t take your opinions on things from HN discussions that claim that Rust is changing quickly, and then are only able to point out 3 things over 5 years that have changed.


I don't. Crate authors seems to be playing catch up to, or more likely, abandon their old work. I'ts really hard coming in to Rust to get a feel for what to use in any given situation as the crates are either dead or in alpha.


Can you point to any evidence that abandoned crates are abandoned due to language changes (as opposed to lost interest by the author, for example)?

Code written for Rust 1.0 will most probably still work perfectly fine today.


How are the Go leadership style and what OP described even remotely the same?

Language safe-guarding, maybe.

Imagine having your production code hostage to your relationship with the language authors...

Go leadership makes me feel like the language is safe and reliable.

The Elm leadership, as described by OP, just triggers my "its a sect" alarm


Is it open source or not? I'm really confused about the answers.


As far as I'm aware there are no features in go that are both fully implemented under a "for me and not for thee" compiler level guard. It's true that end users cannot have generics -- they are reserved for map, slice, array and chan. But that's not because the go team are hypocrites. They just dont have a general solution for generics yet.


I read the post and I don't see the same behaviour in the Go community (the core team banning people who express disagreement or fork the compiler).


There are a ton of Go features that have been asked for by the community that have taken years to get mainlined. I think the most common examples are generics and package management. The authors of the language tended, at points, to be at odds with the desires of many in the community.


Even in those areas, however, Go hasn't done the things that Elm did (according to this article).

There have been a lot of experiments with Go package management, and some did get fairly widespread adoption. After many years, they are getting replaced with an official way, and there are some hard feelings, but experimentation and adoption of alternate solutions was never forbidden. Even with the official system, you aren't locked into the official package management infrastructure; there are flags and environmental variables you can set to use your own servers.

There have also been a lot of experiments with Go generics, often implemented via a preprocessor. I don't think any of these got a lot of traction, but again, they weren't forbidden.

Ultimately, the Go team decides based on what they think is right, but at the same time they aren't so insecure about competition that they need to suppress it.


Maybe, but the Go authors never banned people expressing disagreement or people forking the compiler or the tools.

Almost all programming languages have features being asked by the community and not available as soon as one would hope. Modules in C++. Value types in Java. Removing the GIL in Python. Parallelism in OCaml. Higher kinded types in Rust. Etc.

And most of the time there are pros and cons to adding these features or not, which sometimes evolve in a debate fracturing the community. It even happened to the otherwise peaceful Python community with Guido quitting after the decision of assignment expression: “Now that PEP 572 is done, I don’t ever want to have to fight so hard for a PEP and find that so many people despise my decisions.”


Same with Clojure, where Rich and other core contributors decide for the rest of the community what should be worked on. I think Python is/used to be the same.

Name of this leadership style is BDFL (Benevolent dictator for life) and seems to work for some projects, but you always have people feeling unfairly treated by it, while others enjoy it greatly. Guess that's the effect of being a human :)

https://en.wikipedia.org/wiki/Benevolent_dictator_for_life


Except those BDFLs give you escape hatches to do whatever you want. Elm removed it. It's the same as Clojure, if they didn't let you use your own Java libraries. Or if you couldn't write C extensions for Python. Rich Hickey isn't going to chastise you for resorting to a Java library if you have to, because despite Clojure being an opinionated language, at the end of the day he's pragmatic, which is why Java interop is so readily available.


Maybe this extreme limitation is necessary in the Elm's author vision.

It's open source. You can always fork and implement your own vision. In fact, you're encouraged to do so.


Did you read the blogpost? Apparently you're not encouraged to do so.


https://github.com/elm/core/blob/master/LICENSE

It looks like an open source project. I don't get your point.


Based on the core team communication, if you fork the project, you are persona non grata in Elm.


But that's the point. The community close to the core team is toxic, according to this post. So, there are incentives for the rest of the community to fork the project and have it their own way. There is no need to be in good terms with the core team.


Burning bridges is a risky approach if you are heavily invested in Elm.

I mean in normal communities it's OK to fork to experiment/support your use case but still participate in the mainstream community.


An act being allowed legally is distinct from an act being encouraged socially.


Forking is not the solution to every disagreement.


> 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?

Can you put your finger on each of those and why you think they exist? The only one that makes sense to me is the last one if that means, that people can use hacks and use private apis they were never supposed to use?


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.


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.


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.


Tab width arguments are amusing, because it's always between 2 and 4.

There’s actually a number between 2 and 4. For some reason it's never considered.

I've got a summary of all the indentation arguments here: https://cthor.me/Indentation


I had a CS professor in college who required assignments to be submitted with 3-space indentation.


I can't tell if this is satire or not. Just because a language is open source does not mean it's a perfect democracy.


isn't this the exact problem that tabs solve?


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.


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.


Indent with tabs, align with spaces. Alignment never follows any "N number of spaces" style guide, since by definition its to align with something else.

So in this case:

  <TAB><TAB>function name(arg1, arg2,
  <TAB><TAB>              arg3
since we were talking about indention, not alignment, I don't see how anything changes. If I want my indent to be 3 spaces and you want 8, we can set our tab width and arg3 will still be aligned correctly for both of us.

Or you live with misaligned arguments (its a bit of a smell imho to have so many arguments that you need to split them over many lines, although it for sure does happen) and just use tabs for both.

My main point is that with tab, each individual has some control over their preferences, even if not perfect for alignment, while with spaces everyone has to live with the standard and nobody has control over their preference. That is, tabs is "mostly people get what they want", spaces is "nobody gets what they want unless they happen to want the style guide imposed on them". The former seems a lot better to me!


You learn to live without precisely aligned arguments!

Really this is a peculiar kind of OCD. You don't need to have arg3 precisely lined up with arg1. Or better yet, indent all the arguments in a nice column - if there's so many that they can't fit horizontally, render them vertically. Most IDEs default to two indentations for continuation.


I've had some discussions with folks on projects who are very... focused on linting and formatting rules. They've reformatted my code in the past, and have insisted on blocking code that doesn't pass all their listing rules.

Them: "We have to use these tools to avoid disagreements about spacing and formatting choices".

Me: "But... I wasn't having any in the first place. It's only the 3 of you that were having these disagreements. And now you're spending ridiculous time planning reformat of entire codebase, instead of actually... moving the project forward.

Please don't bitch about me using $x = new Temp(); in a test file. I'm the only person on the project even making test files, and you're blocking my TEST file because you don't like variable name style..."

They got in to a quandary when trying to inline some JS in to a PHP view file. The PHP standard is 4 spaces, and the person doing some of the JS had defined 2 spaces for JS ("so we can all agree on it") and ... all hell broke loose trying to determine what the style/formatting should be for JS-inside-PHP files. 4 spaces? 2 spaces?


> 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?


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


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);


Not the person you're responding to but I do, or actually spacemacs does. The sequence would be $ -> J -> i -> ENTER -> ESC and I guess it's muscle memory.

I agree that this kind of indentation might not make sense on a collaborative project because different people have different standards, but if I'm the only one working on a piece of code I really think precise alignment makes the code a lot more readable.


If the editor would support elastic tabstops you could do:

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


I don't actually personally do this kind of alignment, but it was the easiest example for me to come up with to illustrate the problem of needing to align text on different lines.


In elm you'd do one of two things: keep all the arguments on one line, or put each on its own line. At least, according to the formatter's opinion (which is honestly so nice to use when it just snaps everything into place every time you hit cmd-s). Of course, this convention is violated all the time when listing all the public exports of a package (with good reason IMHO; it lets your group similar things onto lines together) so it's not much of a convention: https://github.com/rundis/elm-bootstrap/commit/e412efe628854...


Go does this with tabs by either having each arg on its own line, or all on one line. Which totally makes sense.


I wouldn't do it, but this works perfectly fine. The rule is "use tabs to indent blocks of code, use spaces to align within those blocks".

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


My main objection to using tabs has always been that the Tab key is heavily overloaded: it navigates (one Tab press to move the cursor to the correct indentation point), selects (tab completion), and it puts a variable-width character into my monospace-defined text file.

I'd rather drop the insertion part and have my editor handle adding an appropriate number of spaces.

Let me add this: there's actually nothing stopping you from displaying a four-space indented file as a two-space indented file. Just parse, replace indentation-dictated groups of four spaces with two spaces, you're done.

I don't know of a plugin that does this for $your-favorite-editor but it's, y'know, software. There's nothing which prevents it.


yeah, but then your Version Control system thinks that you changed the file and it needs to commit that change.

Which is a ton more hassle than inserting tabs.

You could always make CapsLock insert a tab character so you keep the functions of the tab key separate from inserting a tab.


both?


What do you mean?


Tabs for indentation, spaces for alignment. It is called "smart tabs" and good text editors already implement it.


If you use spaces, you can check that files are okay by forbidding \t.

If you use tabs, you can check that files are okay by forbidding /^\t* /.

If you use tabs for indentation, spaces for alignment, ??????


My editor maintains it automatically, so it is never wrong. There is nothing to check.

I'm sure there is a command-line pre-commit formatter I could use. But I have never tried to set it up, since I can reformat existing code with a couple of keystrokes in my editor.


Forbid "\t* *\t"?


Ok, but if you get "\t[space][space][space][space]", how do you know this wasn't supposed to be "\t\t"? That is, how do you know trailing spaces are for alignment and not for indentation?


A code formatter knows, so your editor and other tools can also know.

Most editors have code structure parsing of some kind built-in for tabbing already. E.g. pressing the <tab> key indents the current line to match the structure of surrounding code (or cycles between valid indents for something like Haskell or Python). So they know the difference between initial indentation (that people want to be able to configure visually) and alignment.



You might as well ask if he likes vim or emacs :)


You can't compare vim and emacs, because emacs is more like nano.


Vim all the way >:)


nano or nothin'!


well, yeah. That'll be one way to solve it.


I would have shut that down too. I feel for the maintainers in this case. The stakes are so low.


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

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


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

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


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.


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


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


> The people who write these "I'm leaving X" posts must know they have disproportional power in such a tiny pond.

This is what I find so disappointing and likely why many "thin-skinned" users come out to defend the language when posts like this come out.


> Nobody would even read your post.

Is there anything factual in the post you take issue with?


Oh, I was knee jerked into replying this thread and didn't realised the same comment was made!


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

But he didn't ask for work to be done anywhere in the article? He asks that he not be prevented from writing code that the compiler supports, but which is arbitrarily limited to members of certain organizations. That's not asking for work.

I feel like if you make it so that users of your platform cannot do certain work for themselves, and instead must await you doing the work, you are basically creating the entitlement. You now owe it to them, in some sense, to do the work, since you have intentionally blocked them from doing it themselves.

I mean, it's open source. You have no contract with the maintainers and so there is no real entitlement to any specific behavior. Hell they could have the compiler try to detect whether you're someone who engages in wrongthink and refuse to work for you if so, and you'd have no legal right to complain.

On the other hand, it's plain that there is a certain slice of the population who doesn't prefer this paternalistic approach to software tools. If the Evans of the world wish to remain atop their ivory tower, then they will be the recipients of an incrementally higher frequency of rage-quit posts as a result. Should doesn't enter into it. That's just how it is.

Personally my advice is if you're not into opinionated BDFLs blocking you from doing things for non-technical reasons, don't use ecosystems controlled by BDFLs who have a habit of doing this. So, I won't be using Elm, and that's probably for the best both for me and the Elm core maintainers.


> But he didn't ask for work to be done anywhere in the article? He asks that he not be prevented from writing code that the compiler supports, but which is arbitrarily limited to members of certain organizations. That's not asking for work.

But that is asking for work!

That's a great example of "why don't you just... $TRIVIAL" where $TRIVIAL = "turn off the restrictions", as if there is no consequent problem for the upstream author to have to figure out how to achieve the design goals of the project afterwards, or manage the explosion in issues with modules that may potentially emerge, or who knows which other concerns (I'm just throwing out some guesses; don't take them seriously.)

It's a great example of what Evan describes in the video, of a seemingly trivial request whose potential complex consequences are not seen by the requestor, but are seen and must be dealt with by others; and of conflicting priorities.

Essentially it is a request to the author: "I ask that you spend time to revise your design to figure out how to allow my module's techniques to keep working at the same time as achieving the design goals of Elm going forward, and reverse your design decision that you have already made".

> I feel like if you make it so that users of your platform cannot do certain work for themselves, and instead must await you doing the work, you are basically creating the entitlement. You now owe it to them, in some sense, to do the work, since you have intentionally blocked them from doing it themselves.

You have not blocked them.

As many commenters have pointed out, you don't have to wait, you can fork. You can fork quietly if you don't want social issues from making a big noise, as vast numbers of developers do with a vast numbers of projects.

If the upstream author is not making it easy for the downstream module author, perhaps requiring the downstream author to maintain a patched version of the compiler and persuade other people to use the patch, tough. There's isn't and shouldn't be any moral obligation on the upstream to screw their design goals to accomodate that particular downstream author.

I've had to maintain patched Linux kernels for a project. I didn't resent Linux upstream for that. I didn't complain that I needed to patch the kernel. It was just part of the cost of doing my project. It limited what I could expect to do, but I went into it informed of what to expect.

> it's plain that there is a certain slice of the population who doesn't prefer this paternalistic approach to software tools.

I agree. It's more than prefer for some. A certain slice almost demands it and makes life hard for any author who does not provide. For which the word is "entitlement".

Unfortunately that slice has a subslice who wants something self-cancelling: A non-paternalistic project that talks with them at length patiently, accomodates most requests no matter how varied and contradictory, yet still produces a coherency of design, magic-sauce artefact for them, preferably on a regular release cycle with QA, with nobody's time and personal needs covered.

In other words, what they want isn't always feasible, yet they still demand it from individuals (often via emotional pressure), rather than start their own projects.

> Personally my advice is if you're not into opinionated BDFLs blocking you from doing things for non-technical reasons, don't use ecosystems controlled by BDFLs

I agree wholeheartedly. And that's the advice given to Luke by an Elm developer in 2018! :- https://github.com/gdotdesign/elm-github-install/issues/62#i...

Sounds like Luke chose to ignore the advice, then was angry 1.5 years later. I think it can be argued that the person ignoring the advice is the one who creates the later problem for themselves.

> If the Evans of the world wish to remain atop their ivory tower, then they will be the recipients of an incrementally higher frequency of rage-quit posts as a result. Should doesn't enter into it. That's just how it is.

I think that comes under excusing abuse by saying it's inevitable that someone will do it.

Public rage-posts about someone's work are still abuse if the basic problem is that the other person didn't do what you wanted them to.

What we should have, in a "good" world, is that people like Evan should be able to produce their projects in relative peace without abuse.

If people don't like the project, in the "good" world people know what to expect and are free to start their own alternative.

I think the Evans of the world lose in our current world, no matter what they do. If they are less paternalistic, they will have both an ever-increasing workload until they step down, and the project will not fulfil their design wishes so it's much less rewarding.


> I think that comes under excusing abuse by saying it's inevitable that someone will do it.

Sorry, a former user talking respectfully about the shortcomings of your software project is not "abuse."

However, I do agree with the general thrust Of your comment that it was unwise for Luke to continue to use Elm. For all the reasons he outlines in his post, there are many similarly situated developers who would also do well to avoid it. Luke's post is a public service to let people know that the situation in the Elm project is not very healthy if your needs don't match exactly those envisioned by the core maintainer group.


> Sorry, a former user talking respectfully about the shortcomings of your software project is not "abuse."

I do not agree that Luke's article fits that description.

Luke's post talks not only about the software project, but also about Evan personally. It's not direct but that doesn't matter. (You cannot make something respectful just by phrasing it indirectly.)

He moralises and talks about Evan personally, by implying strongly that Evan does not live up to obligations that Luke has decided Evan has to others, with the additional twist that it doesn't matter if that implies a free-labour obligation.

That was avoidable. Luke could have framed his discussion about how Elm is not suitable to his needs and why others should be aware, in an actually respectful way that did not frame it as a set of obligations Evan was failing to satisfy. But he did not.

Talking about obligations is not always disrespectful, but in this case I think it was.

If you have been on the receiving end of that sort of thing in a public situation, you may or may not have experienced that it can entrain a mass of many people's responses to an overwhelmingly stressful degree, depending on how people collectively respond to it.

People who write such things may not care about that, but these days they have no excuse for being unaware of the possibility. (I don't want to devalue the word "abuse" by overusing it; and for example I wouldn't vote to remove someone from a group I ran for what was written this time, but if it kept happening over and over then eventually I would because I have seen what can happen if action is never taken).


> But that is asking for work!

> That's a great example of "why don't you just... $TRIVIAL" where $TRIVIAL = "turn off the restrictions"

...they put work into creating those restrictions in the first instance, they didn't have to, they chose to, without seeing what it would break for end users.


In Linux, if you are in userspace or are merged into the kernel tree, they won't break you. Otherwise, you can write your code but kernel upgrades can break your code.

In Elm, it's the same but only a select few can get merged in. The rest get told to rewrite into "userspace" (pure Elm) and find their posts deleted or locked and are accused of being "hostile to Elm's goals". Oh, and you have to patch the kernel before it will load your modules, as it downloads from an official website and checks the Publisher field.


I think the Evans just need to be honest about what their projects are capable of. Something like a "please do not build anything that cannot be 100% dependent on packages we have written" notice seems like it would be sufficient. The major problem seems to be that they would like their ecosystem to have the features and support that many other language ecosystems do (such as a rich ecosystem of community-written software), but they are unwilling to cede control to the community in a way that seems necessary to fully support that vision.

That this friction seems to come up constantly seems like it is a failure in messaging. How much energy would the Elm core team save if they didn't have to constantly defend their designs? Then, once the language is at a sufficient maturity to accept community contribution, it could be messaged that supporting development is welcomed.

Instead, you have instances like this one [1], where a developer, misunderstanding the capabilities and goals of Elm, sinks a significant amount of effort into building something that the Elm team has no intention of enabling. Their time has been wasted, they are frustrated, and the Elm team has to once more feel like their goals have been mis-interpreted.

I think purging all non-core Elm packages from the repository, and messaging that Elm is not ready as a general replacement for front-end development tools would save everyone involved a lot of time and heartache.

Of course, the Elm team is free to do as they wish, including fighting a seemingly never-ending series of PR battles over the vision and future of their language. Indeed, this might be the best compromise - they get some amount of ecosystem without changing their vision for the tool. It just seems that there are a lot of bruised egos, and a whole heck of a lot of wasted time because of it.

[1] https://github.com/elm/compiler/issues/1908


You're excluding the middle. There's a third path, which is for the smart people whose goals conflict to listen to each other, have a discussion, and find some compromise solution. This, of course, takes a lot of effort and interpersonal skill, which is not something that we coders are often gifted with.


Thank you fir this. Balances out the prevailing sentiment in the rest of the comments.


The initial complaint was "can you just not do the restrictions in the first place?" which was ignored

It's asking them to do less work


No, it isn't. This point is explicitly addressed at the beginning of the post you're responding to.


The article's criticism about the 0.18 to 0.19 issues is spot-on, but I agree with you that the author comes off as feeling entitled.

The reason why Elm is fun to work with is that it's Evan sharing his hobby project with you. And that's it. There is no support, no long-term maintenance, no implied warranty, nothing. Still, it works for me :) and it is Open Source in the way that I can fix bugs myself, if I have to.

One of the reasons why I chose to not do open source myself is because of people like the author here. You give someone free source code for a useful tool and they'll come back and ask for you to fix their issues.

For example, I once patched a Heroku buildpack because I needed it to work. Due to how GitHub works, my fork was public. A while later, Heroku linked to it. And then I started getting a lot of messages from whiny entitled pricks. Apparently, they thought that it would be my duty to provide support to them. For free, of course, because it's open source...

I'm pretty sure Evan had a similar experience and that's why Elm comes with no support, no warranty, and no way for you to influence it.


If something is just your personal, no-pressure, hobby project, maybe don't convince people to implement it in production?


People have to take responsibility for their own decisions about what to use in production.


personally I believe this is dependent on the marketing. elm market itself as production ready and reliable. that should mean that existing projects will not be scrapped by design.

I mean, this is even worse than python 2/3

I would totally be on elm side if the project came with a "not ready for long term investment or production" with it.

even in the real world this makes a difference. if I tell you that you can freely camp for the winter on an empty lot and invite some friends for free I cannot just evict you because I found someone who would pay. (in the real case likely you would sign a contract where you renounce this right).

similarly a project that invite users to use it loses some rights in term of calling others entitled when they raise some expectations


I guess your perspective on these "gotchas or expectations" changes depending on how invested you are in the language. I worked on an Elm project that ended up fairly large. We started at 0.14, and each version upgrade became progressively more difficult because of changes made to the language and to the runtime. Some of the changes were understandable, such as wanting to change the direction of the platform by dropping FRP, while others were not, such as disallowing inline operators, or dropping methods from the standard library just because the BDFL decided he'd prefer for people to do things differently.

What really ended up bugging me was the patronizing "we're doing this for your own good" response given to every reasoned attempt to question these choices. In the end, Elm definitely had lots of excellent ideas, but I'm happy I don't need to deal with it any longer.


Reminds me a comment made by Rich Hickey https://news.ycombinator.com/item?id=15425632

Quoting top comment: “The presumption that everything is or ought to be a community endeavor is severely broken.”

I believe in the BDFL model but can see history repeating itself. Being open source doesn't mean everyone is equal, and it shouldn't


I think you are missing the whole point of this discussion and it is no way similar to the Cloure/Rick Hickey incident. No one is asking for disproportionate say in language design. Everyone agress on that.

The problem with Elm is their messaging about their production readiness, luring people to try things out for critical production systems and then pull the rug out from under in the name of 'this should be the right way to do things; you are doing it wrongly', when people are already neck deep with their solutions in their production systems.

As an aside, there is no way we can compare Clojure to Elm, as the former is unimaginably brilliant in giving access to the host/target platform (JVM) so that people can get all the benefits of the battle tested libraries of Java/JVM. This Elm saga is completely the opposite. Elm core team is trying so hard to prevent people from using more tested and stable solutions from the JS world without offering them an alternative.


Great talk indeed.

I feel like it might be helpful to online communities to add a real "intent" field to their posting forms, like here in this video: https://youtu.be/o_4EX4dPppA?t=2489


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.


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

What an arrogant and opinionated way to start a documentation.


I remember seeing that repo a few years ago when assessing using Elm for a project. I, also, went with Typescript and React based on that README and the issue full of folks pleading for the package to be restored.


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.


SQL string concatenation is fine. You mean parameter concatenation (into the query string).


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.


there -> their


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.


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.


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

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.


I've watched Elm since its inception when Evan was posting about his experimental FRP project on r/haskell. (Yep, Elm actually started as a functional reactive programming language. That was before The Elm Architecture was developed and all that terminology was thrown out.)

As the project has developed, I have certainly wished Evan had taken a different and more open approach to leadership. I think Elm could be 10x as big as it is right now if he had aggressively encouraged community involvement instead of trying to lock the language down so much.

That said, it's completely mystifying to me how Elm is surrounded in so much drama, and it seems implausible and unreasonable to attribute it all to Evan. In the early days, it started getting hate from some hardcore Haskellers who felt that it needed more sophisticated language constructs. They would have converted it into PureScript, which clearly has never gained any widespread traction either -- perhaps less so than Elm despite all the drama. This is probably one of the earliest sources of conflict where Evan went against what a vocal minority wanted. Since then, it seems to have just snowballed, with the Elm team getting more locked down and vocal users becoming more and more upset about not being involved.

At the end of the day I don't really know what to make of it. Elm would not be Elm if Evan had listened to all the aggressive requests to make Elm more like Haskell. It would still be stuck in FRP-land and 99% of web developers wouldn't be able to make heads or tails of it.

What I will say is this. I have written some internal tools in Elm, and it's one of the best languages I've ever used for web development. It's a revelation of what the web ecosystem could look and feel like in a parallel world. Years later, I would still pick Elm for such projects because nothing else comes close from certain perspectives. I can always go get the normal experience with TypeScript and React. Elm is what I choose for self-contained applications where I don't need and don't care to deal with all the general chaos of the web world. And, personally, I doubt Elm would be this way if the early naysayers had gotten what they wanted.


>Well, simple: think of the rest of us who don't want every user lib to define its own custom operators.

Then why not simply not use those userlibs? Now it seems you're the one draping a blanket, only yours is over a non-specific hypothetical scenario rather than a real-world problem.

The reality is that people have opinions about things. You have opinions about things. People are going to try to manipulate tools they use because nobody in open-source has any significant amount of learned helplessness over software.


> 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


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.


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.


I'm not sure there's a meaningful difference between a strangely shaped operator and a strangely-shaped function. (Indeed they desugar to the same thing, except one is symbolic and one is alphanumeric).

Any decent library will describe the operator in its Haddock documentation, and most will export a named function with the exact same semantics and type.



Hah, you beat me to it.


I think its a bit different with a language though. Because so much of other people's work is based on it, removing a feature that was being used causes all sorts of downstream chaos. Every time a language release breaks backwards compatibility it tends to really upset people, I think maintainers always need to be cognizent that their choices effect others.


They are. They might lose some users this way. They would definitely lose some users the other way though.

I suppose it must seem pretty strange to see a programming language built on a set of technical values, instead of trying to find the subset of most-popular values (because their real goal is popularity).


I've been using Elm happily for 3 years. Thanks for posting this.


Thanks for posting this, it's important.


Thank you! Well put.


It's a peculiar demographic I've noticed amongst people who have grown up with all their software available gratis or ad-supported.

"Oh this incredibly hard work that someone else did for free isn't exactly what I wanted and they refuse to change it the way I want for free"

If Elm is so great, and if it's 99% there, and you only need "this one little custom operator" added, or this "special piece of extension code" and it's really that 1% and you can't be bothered to contribute that 1%; to do it yourself, or pay someone to do it, well, then you deserve to use whatever piece of shit you end up with.


It doesn't sound like they were expecting someone else to do it: they did it themselves but the maintainers were not open to the idea.


What you said sounds exactly like they want the “maintainers” to do something.

But I understand how it can sound like that if you’re part of the demographic I’m talking about.


And when they don't accept your contributions and lock your thread when you explain why you neeed it, what then?


If it’s a good idea your fork will survive.

If it isn’t, now you know too.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: