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

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

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

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.

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.

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

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

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

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

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.

> 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

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

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.

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.

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.

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.

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.

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

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.

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.

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

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

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.

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

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

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.

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.

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

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

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

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.

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.

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.

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.

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

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

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

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.

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.

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

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.

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.

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

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?

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

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

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.

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.

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

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

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

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?

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.

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.

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

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

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

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

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

Good projects die because of bad leadership.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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

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

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

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

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.

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.

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?

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.

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

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

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.

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.

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?

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.

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.

>all the top community contributors left

Please don't pass on misinformation.

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.

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.

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

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

[1] https://ziglang.org/

https://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

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

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

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

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

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

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.

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

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?

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

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.

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

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

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

So in this case:

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

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!

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.

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?

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

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

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

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.

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

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

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.

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.

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

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

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.

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.

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

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.

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

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.

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

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

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.

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

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

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

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.

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.

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

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.

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

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.

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.

What an arrogant and opinionated way to start a documentation.

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