Why I’m Leaving Elm
lukeplant.me.uk
lukeplant.me.uk
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.
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.
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 ...
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?
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.
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 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.
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...
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.
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.
* security patches
* browser compatibility changes
* build tooling compatibility (unless you pin that too, but that never works for long)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.
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
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.)
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.
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".
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.
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".
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.
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.
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.
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.
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.
> 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.
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.
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".
> 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.
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.)
That feels a bit silly - why make a project open source if you're going to get upset when someone forks it?
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.
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?
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.
All of these leavers could've maintained that fabled community fork they want with the features they want if they all got together.
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!”
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.
Choosing to hard-fork Elm and create lots of internet drama just doesn't make sense compared to moving to one of the above.
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.
Good projects die because of bad leadership.
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.
It's as true as it is for Python.
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.
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 :)
It's open source. You can always fork and implement your own vision. In fact, you're encouraged to do so.
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.
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.
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.
Although they did not cave on the Ternary Operator. About which a certain contingent (myself included) is vocally unhappy.
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.”
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
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.
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.
<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.
<TAB><TAB>function name(arg1, arg2,
<TABs or spaces?????> arg3 <-- align with arg1)
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><TAB><TAB>arg1,
<TAB><TAB><TAB>arg2,
<TAB><TAB><TAB>arg3,
<TAB><TAB>)
function name(arg1, arg2, arg3,
arg4, arg5, arg6); <TAB><TAB>function name(<TAB>arg1, arg2,
<TAB><TAB><TAB>arg3)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,
<TAB><TAB> arg3)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!
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.
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
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.
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.
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...
Is there anything factual in the post you take issue with?
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.
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
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
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.
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.
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.
It's asking them to do less work
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.
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.
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.
document.cookie is a security vulnerability that's hard to find in any respectable documentation. It's up there with sql string concatenation.
What an arrogant and opinionated way to start a documentation.
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.
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.
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.
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.
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'm actually curious why; I have yet to see people actually abuse operators outside of C++, and those were in the standard library…
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.
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.
"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.
If it isn’t, now you know too.
But I understand how it can sound like that if you’re part of the demographic I’m talking about.
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.
You can't say the word "guys" in the Slack channel, or a bot will come and correct you, and tell you to say "folks" instead. And from then on, you'll notice the core team all use the word "folks" incessantly in their writing, it's like some weird cult. You'll notice it from the quotes of Evan and Richard in this article.
The forbidden JavaScript FFI is called either "kernel modules" or "native code" despite it being neither. They also claim it's an "implementation detail" or "flaw" despite the fact that it's obviously not.
There are more examples. If you go against any of these rules then you're ostracized.
I quit using Elm because of this problem above all else. I recognize the need to have respectful rules for conversation but having a dialect of newspeak that you're forced to use is just too ridiculous.
Being asked to use inclusive language is a weird thing to complain about, especially as the very first example you give.
> And from then on, you'll notice the core team all use the word "folks" incessantly in their writing, it's like some weird cult.
I use "folks" and other non-gendered language by my own choice. It's a habit I developed after self-reflection. Am I in a cult?
that is, if you consider the word 'guys' as gender bound and inclusive.
Female friends with myself in attendance are often referred to as 'Guys' by waitresses, waiters, and serving staff nearly anywhere I've gone. A former roommate who worked as a server at a restaurant used the word non-inclusively with the same meaning as 'Folks'.
So, first get people to believe the word 'Guy' is inclusive.
It's not.
It's originally synonymous with 'Fellow'[0], which is also from non-inclusive origins meaning colleague, even if 'Fellow' was attached to males in the 50s and 60s common American English.
>I use "folks" and other non-gendered language by my own choice. It's a habit I developed after self-reflection. Am I in a cult?
Good. That's a great choice of habit. I commend you.
Now, please, reconsider 'Guys', it's not as bad as the (current) common tongue might paint it.
[0]: https://www.washingtonpost.com/news/volokh-conspiracy/wp/201...
> that is, if you consider the word 'guys' as gender bound and inclusive.
I think you might be overlooking another possibility. The same reasoning applies if you believe that SOME OF YOUR AUDIENCE considers the word "guys" to be gender-bound. If that is true, then a reasonable person might decide that for the sake of that audience it might be polite to use a different term even if that reasonable person doesn't ascribe any gender to the term.
Somehow your post sounds threatening. I'm guessing it's intentional.
There's one aspect to saying "Hey, we are trying to be ultra-inclusive, and there have been members in this group that feel offended or excluded via the term "guys". To make everyone feel welcome, we ask you refrain from "guys" and use the more inclusive "folks", instead.".
vs
"'Guys' is a non-inclusive and harmful term. Please consider using 'folks' instead."
I don't know how the Elm slack channel has broadcasted this messaging, but the first offers the benefit of the doubt and a chance to understand the situation / learn. The second is just asking to put people on the defensive.
Unfortunately, I've come across the second type of messaging far too often, and it often just induces eye-rolls more than anything.
> Am I in a cult?
Don’t make this personal - the GP is absolutely right that obscure moral proscriptions on language is cult-like behavior, whether or not the people involved are literally in a cult.
Yeah I'm not going to be a part of any community that does this. This is the rust community on STEROIDS.
Is this something that is unique to IT folk? I don't hear about this in other fields, but that might be because I'm not exposed to it.
Or is their something about IT / programming that just attracts these people who are so easily offended / find offence in everything?
Maybe because they are mostly young?
It is not really about people getting offended. The only people who really seem to get offended are the people who insist on using "guys" in spite of a polite request not to.
Language diversity tends to get overlooked quite easily. Remember that just because "guys" is gender neutral in your dialect doesn't necessarily mean that it has this feature for all English speakers across the world. You can't assume as much shared linguistic and cultural background in a programming language Slack channel as you can when you greet your friends at a bar.
That's like saying it's ironic that a taxi driver will let you sit in the back but won't let you drive the taxi.
0.19 introduced a new restriction on Native code (javascript), previously you could compile kernel code in your own projects, now you can't. You've never been able to publish a package using native code to the package site (only packages under the elm or elm-explorations github namespace can).
If you feel strongly about it there are ways around it, forking the compiler, or giving your project a fake "elm/whatever" name so that the compiler will build it, there is also a set of shell scripts on github that allows you to get around the restrictions. I've used it before to make some tooling to track virtual-dom performance.
The biggest miss in the post in my view is not looking more at using Custom Elements for the internationalization needs. Having a custom element where you pass in a posix time and have it formatted using the Intl APIs is very possible, and it also allows you to wrap up the interface between Elm and JS in a nice, type-safe way.
The 0.19 upgrade was fairly large, but manageable. Our app was around 70k LOC when we upgraded from 0.18 to 0.19, the upgrade was fairly smooth, and it hugely improved our build times. I had actually forked the 0.18 compiler to improve build times, full builds took around 2 minutes, and incremental builds around 45 seconds. In 0.19 full builds take 4 seconds and incremental builds less than a second.
I share in some of his experiences as well, I have had posts deleted on the Elm Discourse page for mentioning a way for someone to run a fork of a core package to get a fix. I stopped working on a private package manager for Elm after someone described an existing solution as a hostile attack on Elm.
Overall the benefits of Elm still outweigh the downsides for me, no other language I have used has made development a joy like Elm has, refactoring is honestly fun, change whatever you want, follow the compiler errors, and at the end everything works again. Packages are generally high quality and work, an Elm package that hasn't received any updates in a year probably isn't abandoned, it's finished. Coming back to code I haven't worked on in a while is easy, the type system has my back, and most Elm code looks similar due to using the elm architecture and elm-format.
Who's questions? The author didn't have questions about those things.
And I'm quite certain that the author is well aware of being able to edit a shell script to get around that restriction—and even if they don't, that doesn't change the content of the post.
> The 0.19 upgrade was fairly large, but manageable ..
For _you_, but not for everyone. Can you discount all of the experiences for those whom it wasn't manageable, and for those for whom it was impossible?
> .. an Elm package that hasn't received any updates in a year probably isn't abandoned ...
This wasn't always true. It's one of the reasons why the community forked several packages that authors had abandoned.
> .. most Elm code looks similar due to using the elm architecture ...
Oh dear. There's still so many approaches, and packages, about the different ways that people approach it.
* I wrote Elm professionally for 3 years from 2017-2019
[1] https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#id14
? This wasn't really a technical blog post so I don't think this was a "miss", the points being shared around i18n efforts were meant to support the primary message of the article.
There are trade offs that they are making that I totally understand. There is one way to do things. There is one path to fix things. Everything works one way and works incredibly well.
But those trade offs come at a cost. It is very hard to take Elm into production having to put all of your trust in Evan and the few in his company. There are going to be times that your bugs are not considered bugs by the core team. There are going to be times when your required features are considered harmful to Elm by the core team. Other projects allow you the freedom to work around those sorts of things. Elm has tightened things so this is very hard to do. Elm has made huge wins by doing that. But it makes Elm in production a much harder sell.
I love Elm I want to use it production. But I don't want to have to front to my manager trying to explain we can't do X because I picked a technology that met my needs as a developer but not failed to meet the needs of the business.
Evan has every right to build Elm as he sees fit but it's painful to sit here as a dev and see something so perfect yet have to go for something so terrible for commercial considerations.
Elm achieves simplicity and reliability by having it's entire eco system locked down.
But it turns out the same things that make it a brilliant developer experience make it unusable in production.
I suspect I can and might use it in production but if I do I will be putting a lot of trust in one guy. No one else can really take over.
Having features randomly fail on me and having to rewrite an entire library in elm vs calling out to js means less time creating features that matter to my customers! I was drawn to elm as a way of spending less time debugging my own code in production. Part of that overall strategy means pulling in tested, working code whether it's also elm or js.
Some of what I see here could easily relegate elm to being a toy language; a damn shame considering how good it is as far as strongly typed functional languages to js go.
[0] https://medium.com/darklang/philip2-an-elm-to-reasonml-compi...
[1] https://lobste.rs/s/1jftsw/philip2_elm_ocaml_compiler#c_hahl...
Choose Boring Technology http://boringtechnology.club/
Seriously, don't use up your startup's innovation tokens on some guy's hobby programming language.
Elm helps me come back to these projects after months and, in two cases, a whole year, and get immediate work done without recredentializing in the whole codebase (which I have to do with my React projects to a greater extent).
You definitely can't be a fragile developer to use Elm, and I think the small community size makes people feel like others are obligated to listen to their opinions. Meanwhile they don't expect this from an ecosystem like React because they know nobody is going to listen to them, the ecosystem is just too big with too many people with hobby horses.
I've patched the compiler one two occasions for the 0.19 release. One was to allow me my Debug.crash calls. Elm is updated so slowly that it's trivial to maintain your own patch. Though I ultimately factored out my two patches.
While TFA makes some good points, just like I can enumerate the downsides of all technology that I use, a large bulk of it is just emotional catharsis. And I think this kind of exodus is a good thing. A lot of the people who supposedly leave stick around like a turd circling the drain just to give their aggressive two cents any time something negative can be said about Elm. I've always felt that to be most tiring of all. Kind of like the people who show up in every Typescript-related thread to say how static typing is for lazy developers and what not.
This innocent line has a lot behind it, and probably a lot of PTSD for Elm developers.
The Elm compiler has a --debug flag that would compile with a useful debugging window. It was fundamentally broken for how long? A year?
There were many, many posts about it in that time, several community forks etc. There was little comment on this from Evan or the inner circle.
The debug flag being broken, and seemingly ignored, is a horribly beautiful example of the blog post. Imagine having effectively the only debug tool broken for your main programming language
Elixir (Erlang) has been around for a while and I would venture that the could be considered a little boring.
It's like functional programming. It's been around for a long time and it's safe to use, but some people would call it exotic and be afraid. It's less common, but not exactly novel.
Personally I'd be using JS (or TS) + jQuery. Almost no dependencies, but a lot more manual. No one would be happy on the team if we did this of course. And it can be impractical
I think there is a good free introductory book [1], a welcoming community [2], the language and ecosystem are quite stable nowadays and there's good tooling (now that there's the Spago package manager).
[1] https://leanpub.com/purescript/read [2] https://discourse.purescript.org/
The 'Pure' is the problem here.
Also, these days no one want to learn Haskell just for sake of building UI. Just do it in JavaScript or TypeScript, far far far easier pill to swallow.
Yes I learned Haskell, Elm, and Rust
If the author needs to leave the community, then do it, but no one needs to leave a community with so much drama.
If Evan is entitled to run Elm however he wants, Luke is entitled to post whatever criticism he wants on his own blog.
If nobody ever speaks up, do you think things will actually ever get better?
I think about half that article could be deleted, and it would still hold content of "why I'm leaving," but without building this huge drama oriented narrative.
One person's distress is another person's "drama", I suppose.
Emotions can't be just locked in a cage. They will always filter out.
It actually sounds like one of the issues with Evan, he thinks he is doing the right thing but it's just his ego talking. If he were to listen to how he feels about dealing with this issues and talking to the community Elm would be better off and this article wouldn't have happened.
BTW. I think this article could very well kill elm.
I read this as a thorough recounting of the author's experience, much of which was characterized by a variety of challenges. I suppose that can be construed as having a "dramatic" element.
I feel quite uncomfortable hitching my wagon to a single developer who owes me nothing.
I have a feeling that the answer to the question is like, "What if so-and-so was hit by a bus?" It's like, "It'd be bad." I think that's the general answer but it's something people worry about.
That's... confidence inspiring.
Remember RethinkDB? When they shut down, the software was open-sourced to much fan-fare, but for all intents and purposes it appears progress has come to a screeching halt: https://github.com/rethinkdb/rethinkdb/graphs/contributors
Elm is unfit for any commercial software project IMO as long as it remains a one-man show. I (like everyone else) have limited amount of time to learn new tech, and despite Elm's technical merits - it's not worth sinking any time/effort into it at this time when other more viable options exist.
I tend to place organizations on a spectrum from supportive to controlling. It always is a mix, of course. But open source especially should skew supportive, and this seems like just the opposite.
It seems like the size of the pool of the "Elm disaffected" is large enough by now that a fork of the entire project might be worthwhile.
I imagine there are a lot of software engineers (like me) who at one time used Elm, but lost interest under the leadership of the core team.
Has anyone considered making a compatible fork of Elm?
The author wanted a different language, shouted at a bunch of people for not agreeing with him, those people correctly wrote him off as a productive member of the community, and then he wrote a long blog post about how he can't see their side of the argument.
Indeed, he should use a language that aligns with his preferences. Extrapolating from his experience into this right vs. wrong narrative doesn't actually work.
Even after his explicitly acknowledged troll-like behavior, he didn't get some expletive-laden response from the project maintainers. He wasn't banned from the repos. At no point does he substantiate the idea of the leadership style being 'threatening.'
On the other hand, there are plenty of communities with actual threatening, abusive behavior in plain view, that everyone's aware of. There are plenty of communities that "well actually" every forum post instead of being helpful. Elm isn't one of those.
Suffice to say, I've run into the exact same issues as the author. Had they allowed me to contribute in a meaningful way Elm now would have a nice UI library and probably a much nicer package website which I've developed as well [3] (no longer running, but I've turned maintenance mode off for a few days so you can take a look).
I stopped using and contributing to Elm when 0.19 came out. If you are interested how much effort I put in just check the Elm related repositories in my Github profile [4].
After that I missed the developer experience and I created Mint [5], so in the end some of knowledge I gathered during that time have been put to good use :)
I just can't understand how they could ignore all the work I've put in, if someone would invest that much time and effort into Mint (or any open source project of mine) I would welcome it and or at least start a dialog on how we could integrate their work into the language.
Anyway, I thought I share my Elm story with you (although probably a bit late :))
Cheers
[1] https://github.com/gdotdesign/elm-ui
[2] https://github.com/gdotdesign/elm-github-install
[3] http://elm-directory.herokuapp.com/ https://github.com/gdotdesign/elm-directory
[4] https://github.com/gdotdesign?tab=repositories&q=elm-&type=s...
[5] https://www.mint-lang.com/ https://github.com/mint-lang/mint
Maybe this is answered somewhere, but what would you say is the differentiator between Mint and Svelte? Many of the design choices seem similar. I am in the position of starting a new hobby project soon myself and currently Svelte is the one I have landed on.
Thank you for your efforts.
Mint has what Svelte doesn't:
- consistent language with a good type system - at its base it is a functional language - styling is built in - https://www.mint-lang.com/guide/reference/components/styling... - routing is built in - https://www.mint-lang.com/guide/reference/routing - language constructs for error handling - language constructs for asynchronous tasks - compiles to Preact so the build output is small - easy JavaScript interopability
Svelte has what Mint doesn't:
- it is basically JavaScript compiler - different syntax for template (HTML) vs code - code is just mostly JavaScript and can use NPM packages (I think) - have their own runtime without virtual DOM - transitions and animations are built in - reactive by default (without the need for language constructs)
I haven't really played around with Svelte though so I might be a bit biased. I suggest that you try both a see what you like more.
Let me know if I can help with that :)
I hope more engineers can learn to be this self aware. I know I’m working on it.
Elm is a great language for building frontend apps, I feel far more confident and enjoy writing code in Elm than I ever did in JavaScript / TypeScript. It also feels like Elm is becoming a little more stable and hopefully the big breaking changes of the past aren’t going to be as severe moving forward.
I do wish Evan and the core team were a touch more vocal and transparent about future plans and responsive to bugs / issues. There’s a balance to strike here and it doesn’t feel like we’ve hit the sweet spot yet.
I’ll still keep on writing Elm, as it still brings me happiness. I just hope issues like this don’t have an overwhelming impact of the growth of the community.
Back when I chose Elm, ReasonML and ReasonReact was not around. That is what I would choose instead now. I am currently stuck with an Elm 0.18 app that I'll need to convert to React or bucklescript-tea.
Elm's leadership and as a result the community around it is super arrogant and toxic.
It's really really hard to create a contribution system that works well when there is a large set of users, a large set of contributors, _and_ a tricky design space. It's tempting to become authoritarian, especially when the design space is complex and you've thought about it longer than anyone else. Inclusion is a shit ton of work, and a lot of it feels non-technical and boring to most people.
It's tempting to throw away compatibility and ask users to just deal with it. No project is perfect at this, but infrastructure stuff has a much higher bar for this than most other projects. That makes everything else that much harder.
Most tech culture undervalues management a lot, especially in open source. But open source should be valuing it more, because the problems are so much harder than in a small co-located one-company team -- communication is lower bandwidth and higher stakes, there's no way to manage other people's schedules, there's differing goals and incentives, and on and on.
I work alone so I choose my tech destiny.
But when you look at the guy at which will you are submitting to, and can't but say he is the everything I want from a COMPILER MASTER. He have designed clean and well working language and ecosystem around it.
This is the ecosystem where you are not afraid that one of library's dependencies might install crypto miner or steal your user data.
You are sure with like 99.99999....% that you won't have errors in runtime.
And language is simple, my wife started writing it, you only need to know to structure the code and all the frontend power is to you.
Ad hominem - also Evan is soft spoken guy that cares about his life's work, and sharing it with others.
Ad hominem on my side - I am sick of ALGOL languages. After 12 years of proffesional work with many different languages, touching JS or anything related gave me head aches, such inherently stupid and inefficient ways of building systems, from syntax to /ways of doing things/ and making sure they are /allright/.
Luke may have different ambitions than me, I wanted to build reliable systems that brought me money, for me, after 3 years of Elm, I am happy as I can be.
I build new features with confidence and speed. It took me 3 days of work to switch to 0.19. I have deleted big chunks of JS that I though were necessary in order for my app to work. But I was wrong, there were pure way to do it. That was rewarding mental exercise for me, after which I had cleaner code, and customers noticed performance improvements.
Can language /be better/? Yes.
Is Elm at the point where think it desperately needs some improvement, because of which my work is blocked or stalled? No. It wasn't like that since 0.19.
Luke is off and rude in this post at least. He is considered about the posture of OSS not the real benefits of it. Why Luke didn't came up with big blog post about the features he would like to see in Elm? Much more constructive than bitching about it.
Sounds like he has done a lot of talking about features he would like to see (as well as work to realise them), and gotten nothing but dismissal and inaction for it. I think this blog post is probably the most constructive thing left he could do.
To me Luke, always went in with comments like a zealous OSS knight, which wants to make a contribution so hard.
If you list his blog posts and github comments you will see that there is no constructive critique of technology but rather their way of handling and communicating stuff.
I haven't run to that kind of issues, because I didn't insist do change compiler to suite my needs, but worked with what I already have.
Please, if you find a link to constuctive Luke's criticism, please post it, I am willing to change my mind.
I found him humble, self-aware, forgiving, and kind
> Why Luke didn't came up with big blog post about the features he would like to see in Elm? Much more constructive than bitching about it.
I think you may have missed one of, if not the, fundamental point of the post. Even if he did (which he did at times), it would've been pointless.
...not sure what you're implying about your wife there.
She is accountant turned web designer. After 0 programing experience she learned a bit of JS for about 3 months, started learning Elm - now she works with it day to day for a living (with different clients).
My point is, language is simple enough to grasp it really quickly and start using it productively.
Obviously, the developers of Elm can choose their development style. And those who can't live with that style can fork or fuck off. Still it is sad to see people sore from conflict. The author has a lot of investment in Elm, otherwise they wouldn't have written this. When I need to decide on my involvement in Elm, I will consider how conflicts are resolved.
I understand the purism of Elm, and I know it is part of why I like the language. I accept it takes unpopular decisions to keep it "pure". On the other hand, when I see people break off over limitations that the Elm project places on its users, but not on themselves (one of the main points of that article) I do get a sad feeling. What kind of relationship is this where you trust yourself with compiler features you don't allow other people to handle? Words like patronizing, controlling, and self-serving come to mind. They may have the best of intentions and my protection in mind, but I prefer the privilege to know I can shoot both my feet if I need to.
I've never found the productivity benefits of these JS alternatives worth the risk and cost. There is an understandable desire to move away from the messy reality of JS and it's browser friends, I get it. Having written many thousands of lines of CoffeeScript, experiments with ClojureScript and Elm, I see the appeal.
But you can easily find yourself stranded. Following the herd is important if you want to hire and maintain projects for the long term.
Meanwhile, Elm does a lot of this right out of the box. There's a point where you may be easily reducing complexity and idiosyncrasies by using a tool like Elm.
But moving to a new language that you can't hire for seems like an extreme reaction to "our config is complex". One good thing about a mainline technology like TS is that thinga get attention. Manual config today may be supported feature in the future.
Hoping he'll fare better doing Reason instead. I've tried and haven't had much luck selling it to our local Powers That Be but I understand it's a bit of a nerdy, tough sale.
All Elm developers are equal, but some are more equal than others.
It shows how you can do a lot of things with functional/reactive programming.
Building an app in Elm can be frustrating but it can teach a lot of concepts.
As a completely random internet user evaluating what proglangs to look at next, I'm staying far, far away from elm itself.
Because if so, that really changes the significance of the accusations, in the sense that it makes them almost meaningless. "I wanted Elm to be my new life and my new friends and I wanted to shape it myself as a personal milestone but that stuff didn't happen and now I'm mad and I'm leaving" is a heck of a lot less meaningful to me than, "this language doesn't work well for the problems I'm trying to solve, and the maintainers aren't interested in adapting it to my problem domain, so I'm going to move on to some other language for this thing I'm working on".
I really don't care if someone is pissed that a language development community didn't make someone feel like they belonged to a social club or otherwise interacted with him in a way that satisfied some void inside of him. But if there was some actual purpose to his language noodling, as opposed to being purely recreational, it would be infinitely more interesting to know about how it fell short of the purpose, why the language fell short, why the maintainers didn't want to evolve it in that direction, and what language the author is moving to for their project that does a better job, and why they chose that language. That's meaningful. Anything related to whether or not they felt listened to or if they felt like they were on the inside or the outside is just utterly meaningless, it's like when people complain about news articles that don't have anonymous comment sections.
I realize that to a lot of people, the recreational community aspects of open source development are literally the only thing they care about. But I also realize that to some of those people, they don't understand that this is not the primary purpose of hardly any of the projects they care about, language projects probably least of all. Open source maintainers are not obligated to anybody to create a fun community for recreational users, with a well-lined pathway to becoming a recreational core developer. But that is clearly all that this person cared about, hence all of the emotional stuff which I just don't get. I'm not saying it's invalid, I just don't personally relate to that perspective at all.
For their stated purpose of the article, I wouldn't have found much added value if I had known a lot of detail about why they using and contributing to this language; the message was clear and direct.
I am fascinated with your interpretation of this post as reading that the author was very much desiring and needing social validation and connection. I didn't have this interpretation. Are there some specific things in the post they said that led you to this point of view?
- No runtime exceptions in practice, so you are developing against the compiler and almost never need to manually test what you're writing
- Very opinionated about how to do most things. There's usually just one good library to solve a problem and it solves it in a particular way. What you lose in the process of trying to solve your problem in a way that's not optimal for you, you gain in not having to search for the optimal solution.
- Little politics or debate about the language itself. This does make it like a cult, that's a fair comparison. Doesn't hurt my enjoyment of it though :)
- Tooling is pretty good, with helpful linters, stylers and plugins for vs code, vim and so on that the relatively small community has standardized on.
- Very active community on their Slack, I get considerable help on all problems from syntax to architectural at all hours of the day from certain tireless people on there. I do my part to help as well, I try to help the ultra-newbies now that I'm not one anymore.
I think the type of engineers who "think big" and want to do very ambitious things that would require them to have input on the direction of the language will not be happy in Elm, so I'm never surprised by the posts like this that are quite frequent. HN is especially full of these type so be cautious if this note is applicable. I also don't think I would recommend Elm as the solution to my 2k+ engineer company even though it's my favorite language. There's just too much at stake at that point to take a chance that the Elm process will screw you. But for small projects, maybe under 50 people? I think it can be a very strong candidate.
I.e., date/time formatting, number formatting, and so on.
Isn't this the author's core contention? He really needed an i18n library but wasn't allowed(?) to implement it himself and the Elm team wasn't inclined to provide one.
To add another aspect: The over-management of GitHub issues is, in my experience, borderline pathological.
On dozens of occasions (no exaggeration), I've experienced the following:
- I notice some bug, or some missing functionality.
- After dozens of searches I finally find a relevant Github issue. It's difficult to find because it's closed, in a project with a different, former name to the current version of the package, and part of a now-defunct GH organisation.
- The only comment on the issue was Evan saying the issue is being folded into some meta issue bundling "issues concerning <some broad concept>". He closes the issue and adds a line into the meta issue.
- Any discussion of individual items on the meta-issue is blocked
- Work on that collection of issues is not going to happen "right now" because "it's so much more efficient to work on sets of related issues".
- 14 months or so later, some work is done on <general concept>. The issue is closed (& locked)
- My original issue obviously persists
Evan seems to consider open issues as accusations or personal failures, or otherwise I can't understand why this is happening. When some recent version broke the existing support for WebSockets, the issue was immediately closed (making it, again, invisible to people experiencing this problem and searching with default options).
The most constant output of Elm leadership are long-winded essays explaining how, specifically, you're stupid. You don't get to use WebSockets. We could merge this patch fixing the problem, but anyone could do that. It's just code, after all, and "Code is Easy" (https://www.youtube.com/watch?v=DSjbTC-hvqQ). Have you heard about XY problems? It's a great concept that neatly explains why you are the problem, not us.
I really liked Elm. I would (have) loved to see it succeed. I fully understand that small, young projects come with limitations, that it may take a long time to fix some issue, that backward-compatibility may be broken, etc. Not once have I complained about some issue, Elm or otherwise, not being fixed fast enough. And on the few occasions where I witnessed such a sense of entitlement, I called them out on it.
But the defensiveness of Elm Core to whatever they perceive as hostility has somehow led directly from "benevolent dictator" to this weird kiddy version of Stalinism, where everyone is always upbeat, and "constructive", and prefacing even totally valid questions with five paragraphs of Dear-Leader praise and caveats about probably just being really stupid, lest they trigger the benevolent ego.
I'm just really happy I never used Elm for work projects. I imagine trying to get something fixed when it really matters is a lot like getting ventilators to blue states these days.
— This is an honest question I’ve been holding in all afternoon, and seeing this still on the front page, I just decided to ask.
Yes, the problem is similar. It can be considered worse, because in safe Rust you can do almost everything, but Elm is much more limited.
You can still use regular JavaScript with ports, but it is more complicated. It is something like a WebSocket channel, where the server is the JavaScript code.
I hardly interacted with the community (although I think I remember that slack bot correcting people for using 'guys') but the architecture is both conceptually simple and great and should be emulated.
For those not privy to the Elm tea, a brief primer: this blog post is primarily concerning a months-old issue regarding the removal of the ability to use native modules, which are effectively patches to the Elm runtime[1] which circumvent the core features of the language that provide its greatest strengths: a genuinely helpful compiler and ironclad runtime guarantees (still have yet to encounter a production runtime error that wasn't on the JavaScript side of things!) This "feature" (used loosely) was largely undocumented, always verboten from distribution in user packages, and never intended as anything more than a stopgap measure in extremely rare cases.[2] It was /officially/ not a core language feature intended for widespread usage, and consistently advised against by the Elm team. The removal of native modules was spoken about publicly months before the breaking upgrade. It came as no surprise to me. As an engineer who tries really hard to be responsible, I do not build software which relies on features which are advertised as 'do not use unless absolutely necessary' and are soon-to-be deprecated unless I'm willing to accept the inherent risk of doing so.
The core Elm team was, in my opinion, extremely communicative, well-reasoned, and thoughtful in this change and in others, despite the inconvenience to a small subset of people. For each feature discussed in Luke's post, there is an accompanying Discourse thread[3], discussion on Google groups, Github gists[4], etc., that carefully lays out the reasoning, and carefully consider the scope of a change (in the instance of the removal of custom operators, the Elm team analyzed the package ecosystem and determined less than 5% of packages were affected)[4].
I won't cover the moral arguments around the obligations of open source maintainers as this has been covered ad nauseam with the Clojure and Rust fiascos of a similar sort - though I personally believe maintainers don't owe anyone anything, and I try to treat all free software graciously, as a precious gift, lucky to receive it at all. I will say that Elm's somewhat slow, closed BDFL-ish governance is well-documented as well[5, 6], available to all who seek to understand the Elm development process and decide for themselves if this is an ecosystem to hitch their wagon to. Of course the Elm maintainers get to patch their own runtime with native modules, because they are implementing core parts of the language, it's practically tautological. That users living in userland cannot do it is not unfair; it's a language design feature. What Luke seems to see as a stifling of an open community by the closure of issues and deletion of posts on the Discourse is often basic organizational maintenance to handle redundancies. Conversations around these issues have happened for months and in some cases years, and decisions have been made. They may not be to everyone's tastes. That should be just fine! If someone went to Famous Amos Cookies on Discourse, Slack, their mailing list, and opened a Github issue and PR suggesting this genius idea they just had, it's so good, wait for it - an oatmeal cookie without raisins! - I hope they would clean it up, close the issue, delete my posts, etc., for their own sanity. Not to mention that the opening to Luke's opus here is an admission of his own rudeness to the Elm team on most of these fora. Of course the relationship with maintainers will be strained with this kind of behavior.
There are critiques of Elm, to be sure. The pace of releases is somewhat slow, custom operators might be nice for 3rd party parsing libraries, it might be cool to have a PR merged in to get that fuzzy feeling only OSS contributors get. But you cannot reasonably argue that Elm's team has been unfair, discriminatory, uncommunicative, or arrogant (pathos, so much pathos here!). I don't generally post comments anywhere, but articles like this are irresponsible and damaging not just to the well-being of maintainers who are being generous with their time trying to make something with great care, but to people (like many top level commenters here) who might have tried Elm but won't due to an inside baseball post from a spurned developer. It makes me actually sad, like want-to-cry sad.
[1] https://newfivefour.com/elm-lang-basic-native-module.html (any somewhat experienced Elm developer will get nervous looking at this trivial example and immediately see what might break)
[2] https://groups.google.com/forum/#!msg/elm-dev/1JW6wknkDIo/H9... (2015!)
[3] https://discourse.elm-lang.org/t/native-code-in-0-19/826
[4] https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc7...
We started using elm extensively about a year before 0.19 was released and it was very clear to us from the start that even though it's possible to use native modules, it's a feature that should not be used and will not be supported in the future.
The experience we have had with elm and it's community have been nothing but great.
If we had stumbled upon a blog post/ thread like this when figuring out how to proceed, I'm not sure we would have given elm enough thought and tested it out properly. This makes me really sad as well.
Here's an interview from 2017 with Evan where he discusses Elm's approach to interop. https://elmtown.simplecast.fm/b06499a6 Skip to about 8.5 minutes in.
While Luke's approach certainly could have been better, I don't think it had any bearing on the result. The reason for not allowing Javascript into Elm libraries seems fundamental to what Elm is trying to achieve.
- Firefox isn't Open Source.
- Lots of other things often held up as shining examples of Open Source are not Open Source.
...because they are worked on by people or teams who decide their own design goals and roadmap, and while you can contribute and talk about the project, many users feel the project moves on without catering to their needs or remaining compatible over time.
Firefox is an interesting example, not only because it's a poster child for Open Source, but because it evolved from Netscape Navigator's source release and is associated with events when the "Open Source" term was being coined.
My understanding about why the core team is being so controlling over the native modules access is that they're trying to prove that each native module is pure, so they can make assumptions and declarations in the compiler that the code produced is pure. By forcing unblessed/unreviewed modules to use the ports interface they can maintain this assumption. Without doing this you lose all of that assumption and your compiler falls apart, if it's based on that assumption.
I have used Elm in a hobby project, a multiplayer web game, which I have been developing over 4 years now. Elm has been a complete joy. New features and refactors are done incredibly fast AND safe. I believe this is due to Elm's restrictions letting no unsafe code "in".
Perhaps its a case of wanting something for nothing...this is a long post and a lot of mental energy better put into a fork, and getting like minded folk involved. New users also quickly discover that the language is unsuitable for use, there would be many interested in such a thing.
But with Go, at least it's the community as a whole making the decision to be like that - people might shy away from cgo, for example, but it's a convention, not a hard limitation. And if you do decide to use Go in your app, you still get to choose how much or little of it there will be.
With Elm, it seems that there isn't any community consensus along these lines, or even a community in the same sense (i.e. that can establish a consensus that would be meaningful). It's practically a religion - you get the rules delivered to you on stone tablets, and you're either all in or all out. Except in this religion, there are new stone tablets every couple of years.
It might be an overly uncharitable comparison, but I can't help but remember https://wiki.lspace.org/mediawiki/Abominations_Unto_Nuggan. Especially "Abomination 6543: Umbrellas or any other Devices that shield the wearer from the Blessings of Nature", in the context of native/kernel code.
Especially when the wrapper decides to take away the escape hatches, locking people into its opinions without considering genuinely valid exemptions.
I wonder how so many truly bright minds, bought into this philosophy, despite knowing this was coming. I guess the promise of Elm was just far too convincing.
Rather than compound problems with unnecessary incompetence and calling it functional and typed. The only thing typed I discovered is undefined incompetence from Elm to C++.
There is always an excuse to complicate problems when you are incompetent and invent useless languages.
There's a lot of convenient, and perhaps subconscious, confusion of terminology in technology. For example, people can point to the fact that a project isn't 1.0 yet and argue "well you should have known anything goes pre-1.0". But Linux was amazingly solid prior to 1.0, and even the term "Beta" has been watered down by Google's infamous insistence of using the term for ages on their software. I'm not saying you have to agree with the watering down of technical meaning, but you should understand the unfortunate reality that a lot of this is mixed signaling. For example, a common one is "It's beta but we use it in production and it works great!", which if you break it down is kind of a used-car-salesman technique. It's saying "I've created plausible deniability for myself so that I owe you nothing, but the final thought I'm going to leave you with is an emotionally manipulative statement that wink wink it's really ready to go".
Similarly, if you have a fancy landing page telling people why your product is better than other production-ready products, for example Elm compares itself against Angular, React, and Ember, then you are strongly implying you are a peer. So even though the words "production-ready" don't appear on the page, there is a strong implication here. There's certainly no asterisk anywhere saying "pre-shipping numbers", something that game trailers will even do. Again, I don't think this is intentionally deceitful, I think it's supremely easy to accidentally run into this sort of messaging. But you should absolutely be mindful of this and work against this.
Luckily, this is all fairly avoidable if you're willing to take some simple steps. For example, just say "this is a toy project" or at least "We absolutely do not recommend this for production", or even "the primary purpose of this project is for researching ideas that interest me". That can completely avoid any miscommunication and sets expectations up correctly, and furthermore puts you 100% in the right in the event that someone ends up relying on your code... But no one wants to do that because it hurts adoption! This is what I mean by wanting to "Having Your Open Source and Eating It Too". You want to portray an amazing product that does everything well AND is a happy community, while reserving the right to treat it like a side project whenever you want.
It's seems like 0.18 to 0.19 was a divisive upgrade for the community. I feel like a lot of good languages or frameworks go through this existential crisis at some point. There was Python 2 to 3, or Angular 1 to 2, Node vs IO, etc.. I think Vue narrowly avoided it on it way towards 3.0 (maybe remains to be seen). I remember when Rails community split when Yehuda Katz got frustrated with DHH and made Merb, and then they merged back together for Rails 3.
It seems like open source has a love/hate relationship with the benevolent dictatorship model.
"""
Miso was written exactly for Haskell enthusiasts who want the simplicity of an Elm interface without sacrificing too much performance. The benefits I’d say are thus:
• Type sharing. A lot of web dev becomes boilerplate -- serializing and transferring state is a large part of the work of web dev. Type sharing ensures correct-by-construction serialization between server / client amidst any changes to your business logic data types, allows you to focus on your apps core offerings as opposed to minutia.
• Rich ecosystem. The Haskell ecosystem has many great libraries that compile w/o any problems on the frontend.
• Concurrency. Programming with threads and synchronization primitives is now first class in the browser.
• Extensibility. Compared to Elm’s ports feature, the GHCJS FFI is a much simpler way to interface with third-party libs. Also, Haskell supports typeclasses, and Generic programming, a rich lens library, etc.
• Community involvement. You’ll be working directly at the intersection of a lot of interesting developments in GHC, specifically around cross compilation, syntax, lenses. Any new advancements to GHC has an impact on your frontend code. Also, many PhDs use, love and contribute to Miso. These people tend to be very smart, empathetic and intellectually curious as opposed to dogmatic and contentious that can be found in the software engineering industry at large today.
• Nix, a one-tool-to-rule them all for dev, build, and deploy. While not easy, deterministic builds are the future and help one to sleep at night (I’ve found). It can be used solely for personal dev, or for an entire organization, and anything in between.
• Virtual DOM. If your Haskell web framework does not handle the tedious task of DOM manipulation for you, you have been failed as a library consumer IMO. Miso has a very well-tested, simple recursive micro virtual DOM diffing library that can exist standalone and can detect regressions in performance via a benchmark suite.
• Simplicity. Unlike many other ivory tower libraries in Haskell, Miso maintains a simple interface. Many different common abstractions were explored in the early stages of development (free monads, FRP, etc.) and found lacking, unnecessary or replaceable by a simpler solution without sacrificing features. Miso does not attempt to hide behind complex type-level abstractions and blame end-users for their lack of understanding. As opposed to a top-down approach that shoe-horns an abstraction into an environment where it does not belong, Miso takes a bottom-up approach to fully understand its environment, the browser, it’s APIs, the DOM and its short-comings and provide a simple commonly-used abstraction to the end-user that can scale to large applications. This also makes it easier for newcomers to Haskell to get up and running quickly.
• Industry adoption. Several companies are using miso in production for various things in their company, from full product to internal tools / data visualization.
• Isomorphic. Due to the rose tree structure of both the DOM and HTML, pre-rendering increases load-time and overall UX along with correct SEO.
"""
^ from the author of Miso
Miso was written exactly for Haskell enthusiasts who want the simplicity of an Elm interface without sacrificing too much performance. The benefits I’d say are thus:
• Type sharing (A lot of web dev becomes boilerplate -- serializing and transferring state is a large part of the work of web dev. Type sharing ensures correct-by-construction serialization between server / client amidst any changes to your business logic data types, allows you to focus on your apps core offerings as opposed to minutia).
• Rich ecosystem (the Haskell ecosystem has many great libraries that compile w/o any problems on the frontend).
• Concurrency (Programming with threads and synchronization primitives is now first class in the browser)
• Extensibility. (Compared to Elm’s ports feature, the GHCJS FFI is a much simpler way to interface with third-party libs. Also, Haskell supports typeclasses, and Generic programming, a rich lens library, etc.)
• Community involvement (You’ll be working directly at the intersection of a lot of interesting developments in GHC, specifically around cross compilation, syntax, lenses. Any new advancements to GHC has an impact on your frontend code. Also, many PhDs use, love and contribute to Miso. These people tend to be very smart, empathetic and intellectually curious as opposed to dogmatic and contentious that can be found in the software engineering industry at large today).
• Nix, a one-tool-to-rule them all for dev, build, and deploy. While not easy, deterministic builds are the future and help one to sleep at night (I’ve found). It can be used solely for personal dev, or for an entire organization, and anything in between.
• Virtual DOM. (If your Haskell web framework does not handle the tedious task of DOM manipulation for you, you have been failed as a library consumer IMO. Miso has a very well-tested, simple recursive micro virtual DOM diffing library that can exist standalone and can detect regressions in performance via a benchmark suite).
• Simplicity. (Unlike many other ivory tower libraries in Haskell, Miso maintains a simple interface. Many different common abstractions were explored in the early stages of development (free monads, FRP, etc.) and found lacking, unnecessary or replaceable by a simpler solution without sacrificing features. Miso does not attempt to hide behind complex type-level abstractions and blame end-users for their lack of understanding. As opposed to a top-down approach that shoe-horns an abstraction into an environment where it does not belong, Miso takes a bottom-up approach to fully understand its environment, the browser, it’s APIs, the DOM and its short-comings and provide a simple commonly-used abstraction to the end-user that can scale to large applications. This also makes it easier for newcomers to Haskell to get up and running quickly).
• Industry adoption. (Several companies are using miso in production for various things in their company, from full product to internal tools / data visualization).
• Isomorphic. Due to the rose tree structure of both the DOM and HTML, pre-rendering increases load-time and overall UX along with correct SEO.