I'll second this. I've read many "why I'm leaving <x>" posts and regardless of the degree someone might agree/disagree with the contents, it's a very fair article. That's difficult to pull off, I'd say.
> For example, if there is a bug in any core library, or something missing, you just have to wait for the core team to fix it, rather than being able to fix it yourself. You might need a performance fix, which can be done using Javascript but not in Elm (lack of destructive updates makes some things very hard to implement efficiently), and again you will be stuck having to explain to your boss “I know this is possible in Javascript, but we chose Elm and it makes it very hard”.
Hard pass on Elm if this is true. This is an incredibly damaging accusation, is this consistent with other people's experience using Elm?
this is, at least, consistent with my experience using elm on a side project. Dropped elm like a hot potato when I hit that wall.
frustrating, too, because I was really enjoying the language, and everything about it up to that point. The tooling support for Elm is REALLY solid compared to some other functional compile-to-js languages out there.
If anyone is looking for a good functional compile-to-js language, I would suggest taking a look at ReasonML or possibly ClojureScript. Personally, I've just been using TypeScript written in a functional way, and it serves my needs at this point.
My brief experience has been similar. Elm is a dictatorship that could be wonderful if it didn't exist in the realm of messy html/js. I experience an icky feeling of stockholm-syndrome part of the time, and just plain frustration at other times when dealing with Elm.
What's infuriating is that I do see the benefit of some degree of strict stewardship. It's just that it's too much in this case.
I totally agree with this fustration. There seems to be some innate paradox between growing a community and being a BDFL. I think this also expresses is self in our current political environment.
This isn't a programming discussion. It's a discussion of the policies around an open source project. It's totally politics, albeit not on a national scale.
The use of "dictatorship" in your comment brought a smile to my face because I thought of the BDFL title given to Python's creator ... and then imagined the Elm team forgot the "B" at the beginning of the acronym. Note that I have no personal experience with Elm and am in no position to take sides. The comment just describes the mental image I got from your comment's ink blot.
Most dictators believe that they are benevolent, as does their close circle (which is then often seen as "the community", because it has the loudest voice). From the blog, it definitely sounds like this is the case for Elm.
If you feel the same way about the Elm project as the author of the article does, you won't be happy with Clojure[script] either. Its community already went through this drama and all the top community contributors(or that at least tried to contribute) left.
I can't speak to Elm, but I'd say the Clojure/Script fiasco wasn't really one sided. Some of the "contributors" not getting their way wasn't like they were wanting to push some amazing improvements. Most of the time, the reason for things not going through is actually disagreement on the impact the change would have to the language, and people complaining about how slowly the discussion around it can happen to drive agreement.
Basically my point is, some people like me are happy that there's a high bar of entry for contributions and that every change is carefully considered, even if sometimes that means changes happens more slowly.
if that is the source of the drama for ClojureScript, there is a huge difference between that and the issue with Elm. With Elm 0.19 they have effectively disabled all libraries that use native JavaScript within, unless they are officially approved by the Elm core team, which I understand is no small feat.
Imagine in Clojure if they said "you can't use Java libraries any more. Pure Clojure only from now on" but kept the ability to use Java libraries for the core libraries of the language. -- That is my understanding of the issue with Elm as it currently stands.
Oh, that's a bold move. I doubt this would happen on ClojureScript, in fact, I see the opposite sometimes, some people in the community complain about how Java and JS ruins Clojure/Script and makes everything worse, and why isn't there a native Clojure, where you'd never have to deal with the host. And the core stance tends to be that being hosted is the whole point from the beginning.
I can see the frustration with Elm though, especially that it was enacted as part of a version upgrade. If it was from the start, people would know what to expect, but this seems like a huge backward breaking change. I'd be annoyed as well.
In Clojure/Script, a lot of the tensions are more about what should be a community provided library, and what should be lifted as officially included in core. I see the core team tends to favour most language extensions to be kept as a library. And often when people want changes to the language to be made, the answer is that Clojure/Script is designed to allow user level changes, so whatever you don't like you can change for yourself. Some people still arn't happy about that, they want their ideas to become the standard.
A lot of that stems from it being a Lisp. There's very little of Clojure/Script that actually necessitates changes to the compiler itself. Even the core functionality, most of it is implemented on the basic primitives the compiler gives, so you can happily change and extend almost anything if you disagree with the core team's choices.
Back to Elm, I know personally, I've never been into a language restricted to only one use case, the web. It seems Elm has always wanted to be more of a framework for web development. A very opinionated one. This seems to be a move even more on that direction. Like if Ruby didn't exist, but only Ruby On Rails did. Correct me if I'm wrong here. It could lead to something nice in the long run, but like any framework, the trade off is that when it doesn't have the feature you need, you're stuck.
Did you ever try Scala.js? I was a huge fan of how fully it was just standard Scala and therefore well-supported by IntelliJ; I've not seen any other compile-to-JS language match that level of IDE experience (but as someone who was already a Scala fan I'm biased).
It didn't when I tried it - IntelliJ does support it on some level, but doesn't offer the same depth of automatic refactoring etc. that you get with Scala, to the point that my colleagues generally favoured using VS Code.
Unfortunately ReasonML has its own set of drawbacks which don't make it a drop in replacement. These issues include standard library incompleteness, inconsistent parameter ordering conventions, and poor compiler error messages (compared to Elm).
I just feel like people are right that the core team is not reasonable but at the same time, if there are that many people that like Elm, why not create a total fork?
It might come down to the people that would care enough to do the fork and a server or whatever have already had so much Koolaid that they just accept those negatives. And the other ones that can't accept it don't like it enough anymore to go to the trouble of making a fork.
But to me it seems like the best outcome is a fork that becomes successful.
This perfectly describe the situation. While it is possible to do it yourself in Elm without the update, it is quite hard and cumbersome to do so. It is much easier to make a PR, but Elm core team is purposely relationship and personal-trust based, any random PRs will not get accepted in foreseeable future.
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.
Started following Luke back when he was doing a lot of Django work. He's not the type to do things "just cuz". Most of his work is well thought out and very reasoned. Big fan of the guy honestly.
Long, but I think reasoning was explained very nicely without it reading like an attack on anyone in particular. I would love to read a nice response to this, but personally I will not be looking to use Elm anytime in the future.
Agreed. I initially groaned at the length, but I think it was necessary to make his case. This isn't the first time I've heard complaints about Elm leadership like this. And I especially appreciated his nuanced take on open-source projects and entitlement.
I tend to place organizations on a spectrum from supportive to controlling. It always is a mix, of course. But open source especially should skew supportive, and this seems like just the opposite.
We had a pretty similar experience with elm around cookies. The elm-lang/cookie repo README starts with "Cookies are an ancient mistake of web browsers. They make a bunch of security problems quite easy, so consider this an expert library." However, they never address reading cookies, so if you're using a framework that does CSRF protection with cookies, you have to use ports, which adds quite a bit of complexity for something as simple as making an API request.
Elm looks great on the surface, but once you start digging in you really start to realize it's "there" way or else. It's too bad, the ideas have a lot of promise, but we pivoted away quickly after running into the "core arrogance" a couple of times and went with Typescript/React/Redux.
I remember seeing that repo a few years ago when assessing using Elm for a project. I, also, went with Typescript and React based on that README and the issue full of folks pleading for the package to be restored.
Well, you should be using `httpOnly` cookies (i.e. unusable from the browser) and setting them from the server. Your browser client will automatically send them.
document.cookie is a security vulnerability that's hard to find in any respectable documentation. It's up there with sql string concatenation.
> The elm-lang/cookie repo README starts with "Cookies are an ancient mistake of web browsers. They make a bunch of security problems quite easy, so consider this an expert library."
What an arrogant and opinionated way to start a documentation.
I've been working in Elm for a few years, and I feel like I can answer some of the questions.
0.19 introduced a new restriction on Native code (javascript), previously you could compile kernel code in your own projects, now you can't. You've never been able to publish a package using native code to the package site (only packages under the elm or elm-explorations github namespace can).
If you feel strongly about it there are ways around it, forking the compiler, or giving your project a fake "elm/whatever" name so that the compiler will build it, there is also a set of shell scripts on github that allows you to get around the restrictions. I've used it before to make some tooling to track virtual-dom performance.
The biggest miss in the post in my view is not looking more at using Custom Elements for the internationalization needs. Having a custom element where you pass in a posix time and have it formatted using the Intl APIs is very possible, and it also allows you to wrap up the interface between Elm and JS in a nice, type-safe way.
The 0.19 upgrade was fairly large, but manageable. Our app was around 70k LOC when we upgraded from 0.18 to 0.19, the upgrade was fairly smooth, and it hugely improved our build times. I had actually forked the 0.18 compiler to improve build times, full builds took around 2 minutes, and incremental builds around 45 seconds. In 0.19 full builds take 4 seconds and incremental builds less than a second.
I share in some of his experiences as well, I have had posts deleted on the Elm Discourse page for mentioning a way for someone to run a fork of a core package to get a fix. I stopped working on a private package manager for Elm after someone described an existing solution as a hostile attack on Elm.
Overall the benefits of Elm still outweigh the downsides for me, no other language I have used has made development a joy like Elm has, refactoring is honestly fun, change whatever you want, follow the compiler errors, and at the end everything works again. Packages are generally high quality and work, an Elm package that hasn't received any updates in a year probably isn't abandoned, it's finished. Coming back to code I haven't worked on in a while is easy, the type system has my back, and most Elm code looks similar due to using the elm architecture and elm-format.
I would say the name is fine in terms of the Elm runtime. This is not about JS modules, but about calling the JS API of the browser and also managing some state there.
> I've been working in Elm for a few years, and I feel like I can answer some of the questions.
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
> The biggest miss in the post in my view is not looking more at using Custom Elements for the internationalization needs
? 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.
I haven't used Elm, so I have no horse in this race. But I feel like I've been hearing these stories for a while, that it started out as an interesting and useful language but kept having features removed in new versions. Since it's open-source, and apparently there are existing projects in older versions of Elm that would effectively be held hostage by these feature removals, I'm amazed there hasn't been a (well-known) fork yet.
Has anyone considered making a compatible fork of Elm?
This criticism is spot on; it is exactly what I observed in late 2018, early 2019 as well. It's an awesome language, but there is basically a big case of 'vendor lock-in'. Certain compiler features are only available to the maintainers, nor is there any way to use alternative package sites.
I don't want to know what would ever happen if the Elm developers decide to take https://package.elm-lang.org offline. That will leave so many projects out there in an unbuildable state. Even if you saved source tarballs of the core packages, there is no way to tie it into the build yourself. The Elm compiler must load it through the official package site.
I would thus personally strongly advise against using something like Elm to build any piece of software that needs to be maintained over time. It's too much of a risk.
That's not correct, you can just inline any package into your vendor folder in your project.
And the package website is just an index, the sources need to be on github in the first place (this has some problems too), but if the website is down, you can still grab them from github.
> This criticism is spot on; it is exactly what I observed in late 2018, early 2019 as well.
These issues were obvious much earlier than that. I looked into Elm and was excited about it initially, in either late 2013 or early 2014. Then I looked into the history of some of the design decisions that baffled me (such as lack of type classes) and concluded the project was poorly conceived and led. The leadership didn't respect the opinions or capability of its end users.
> The leadership didn't respect the opinions or capability of its end users
This was the major sticking point for me when it came to Elm. I invested a lot of time into Elm and even published a few packages. Many things contributed to my giving up Elm, but the final straw for me was when the core team removed some userland APIs under the guise of "we can't trust developers not to use these to write bad code". Myself and several others tried to convince Evan to reverse this decision, to no avail.
Wow I never knew how much I loved typescript until reading this. Never had a blog post worth of complaints, at worst just cast to ‘any’, write a comment to recheck after the next update, and clock out at 5. And maybe pray for forgiveness from God for my code having side effects if I’m feeling guilty.
The last time I looked at Elm was about ~4 years and this attitude was already showing. We hesitated building our business front-end in Elm at the time and had a general bad feeling about its future considering the various interactions we had seen. Seeing this article makes me pretty glad I didn't invest time in Elm.
Same. We founded on Haskell but had some need to more front-end oriented code. Can say Elm was never considered because I was hearing this weird stuff back in 2016--not to mention it would just make hiring even harder. Can't trust tooling that will be capricious.
Typescript. We try not to be type/pl theory fanatics. Choose your tools well. Haskell is great since the core of our product is an interpreter/compiler with multiple stages. But I don't wanna use it everywhere.
Personally I'd be using JS (or TS) + jQuery. Almost no dependencies, but a lot more manual. No one would be happy on the team if we did this of course. And it can be impractical
Same.. was looking at make machine control system web HMI in Elm. After some investigation into Elm's background and development team... saw too many warning signs.
I don't agree with everything here. Open source really does mean that you just have all the code to rebuild the thing from scratch under the right sort of license. Open source doesn't mean anything else, like having access to design decisions.
Interaction style and personalities are also not part of the definition of open source; open source doesn't mean nobody is brusque or abrasive. Some communities have additional codes of conduct and social contracts and what not for that sort of thing.
Here is a balanced viewpoint from the GNU Awk and Bash maintainers:
Elm users who are not happy should fork the code --- everything, including the ecosystem's dependencies on an ELM internet domain --- and maybe produce something that is completely self-contained. Software that relies on "phoning home" is a risk regardless of where that is hosted and whether the people are nasty or nice.
If the Elm core developers don't like it and kick people out of their project for forking, you just have to bite the bullet on that.
(From the description of what that project is like, why would you care about being kicked out. Kicked out or not, your 20 line bugfix still isn't getting looked at for another two years.)
That's right[1]; and the author of "Why I'm leaving Elm" understands this, yet claims that it's not possible somehow because the Elm people are hostile to it, and that's one of the reasons the project supposedly isn't really "open source".
Something seems a bit off in the reasoning. The only reason you can't fork something is that either you don't have all the code, or there is a license problem.
One way not to have all the code is that there is a dependency on specific SaaS server installation, whose source code isn't available. If that's the case with Elm, I missed the coverage of it in the article somehow. I did get the part that the packaging ecosystem depends on a particular server controlled by the Elm project.
1. Well, not a solution for the project, but for some of its unhappy users. The project, as such, perhaps doesn't even feel that it has these problems that require solving.
He doesn't claim it's not possible, he claims that the Elm community will excommunicate you for forking.
I can't think of a language or platform that doesn't have some degree of "soft" forking that maintains communion with the language community. It's common for proprietary reasons (linux kernel, anyone?) as well as experimental reasons (e.g. PyPy). So this is an eyebrow raising claim.
On the face of it, my impression is that excommunication, if it happens, is more likely to be caused by the author being burdensome to deal with, than code forking per se.
Of course the author is unlikely to present it that way.
And although I felt the author was moralising in this critique, it may be they are not particularly rude the rest of the time. But even writing a plethora of well-reasoned but difficult to handle posts about what's wrong with your project can be too much.
Well-established languages, platforms and projects such as Linux that have a large labour pool with socially-established patterns of working don't have the same problem, because there's enough labour to deal with it.
Smaller projects just have to turn people away when they become hard work beyond the capacity of the project's core maintainers to handle it, though.
The solution found via FLOSS is to license software so that forking is always possible when a project cannot sustain different visions for the project's direction. This diffuses the tension when people have incompatible needs from the project. Sometimes it comes with drama, particularly if people are competing for attention and trying to persuade others to follow them, but that seems inevitable because of the competition.
It is still understood that forking is permitted and intended to be part of the solution, and the social niceties are that you may be encouraged, perhaps strongly, to go away and run your own fork yourself with your own resources, under a new name/domain/etc. while acknowleging where it came from. Then it's your own job to build a reputation too; it's only fair.
It's very difficult to keep running a project while your competition lingers on the same mailing list, constantly funnelling people towards their fork in the hope of making it more popular. That's a very good reason to "excommunicate" some people, or to forbid some topics such as advertising the other project repeatedly.
> Of course the author is unlikely to present it that way.
I don't really get this accusation in light of the author leading the article with admissions of their own failings in terms of how they communicated with the maintainers of the project?
I'm writing in response to this remark, presented in the parent to my comment:
> he claims that the Elm community will excommunicate you for forking.
If that is correct, what I said is less accusation and more descriptive, and should really say something stronger: "the author hasn't presented it that way."
However if the parent to my comment is mistaken, then I agree that would make that sentence in my response unfairly speculative.
The bit about "excommunication" is very explicitly linked to the author's plan to fork Elm. Now, I don't think "excommunication" is necessarily the correct descriptor. The Elm maintainer who made the threat said that he considered making a fork on "attack" on Elm's goals [1], and that the project would not be greeted with open arms. (Although in the original comment it was a little less clear whether it was the project or the person to whom arms would not be open.) In any case, I think the comment is very clear that the hostility is to the action of forking, irrespective of previous communication problems.
I don't see anything about making a fork in the linked GitHub issue.
(The word "fork" appears once elsewhere, in an unrelated context in a different comment.)
The thing about open arms is not about forking (or if it is, it's not obvious to me), and reads to me more like "assuming you are not making your own fork, can you please stop pressuring upstream to accomodate designs which are explicitly against our clearly communicated design goals".
The quote is:
> @spookylukey It's one thing to build tooling around an implementation flaw without knowing the history, but that's all pretty well communicated at this point.
> If you understand the design goals, but don't agree with them, why not channel that in a positive way - e.g. by building something that fits your vision instead of directly working against Elm's design goals?
> As someone who has spent a lot of time collaborating with many others to help Elm achieve its stated design goals, intentionally working against those goals feels to me like an attack on our efforts. We have been really clear about our design goals in this area, and you shouldn't expect a project that works against those goals to be greeted with open arms—especially not from those of us who have been working hard for years to achieve those goals.
The comment immediately before rtfeldman's references patching the compiler for this project, which is an implied necessity if js code is to continue to be used. It's essentially a soft-fork, and that is what rtfeldman is objecting to.
Thanks, fair enough although rtfeldman appears to be responding to spookeylukey about divergent design goals, while it's norpan who is talking about maintaining a locally patched compiler.
I still see no objections to maintaining a fork or local patch from rtfeldman. Just "if you go against our explicit design goals don't expect us to want to merge it upstream for first-class support".
TBH a locally patched compiler sounds like not a huge deal to me. I have lived with locally patched GCCs before :-)
But maybe I'm unusual. I surprised someone, once, when they found some code not working and I suggested they look at their compiler source for the cause. Their response: "Wow, I hadn't ever thought of the compiler as something that might have a bug, let alone read and modify it".
IT was norpan and spookeylukey talking about patching the compiler together, and rtfeldman jumping in with references to PAST discussions of design goals with spookeylukey.
What would they do? I'm not sure there's an actual threat to follow through on. They can't block a forked compiler from, for example, using official packages without close-sourcing their own compiler (to prevent it from bringing in whatever change makes it work again).
At that point, why bother respecting the threat? A forked compiler isn't going to get maintainers? A package depending on the forked compiler isn't going to be maintained? The social cost is possibly something to think about, but if one is set on leaving the community anyways then it's a choice between you choosing to not interact with the community and them (possibly!) choosing to not interact with you.
It's still worth knowing that they're being jerks about it, since that falls outside of the social (but obviously not the legal) aspects of open source.
> falls outside of the social (but obviously not the legal) aspects of open source.
Not really, IMO. Forking a project used to be a really aggressive thing to do back before GitHub made it so common among younger waves of developers.
If you go to Evan and say, "Look, I want to use your thing but do it my way." and he says "No, I have a clear vision of what the thing is and it's not that. KTHXBYE." I don't think that's "being a jerk".
The community is more valuable than the code, because the community writes the code. So being cut off from the community is a major blow to a fork, and substantially increases their work burden.
Your fork isn't a significant amount of work, unless they've really threaded in the must-be-in-Elm-Kernel check throughout the entire compiler. Versus trying to rewrite your dependency in Elm rather than enabling importing JS, enabling JS is likely to be simpler since the functionality already exists to let Kernel modules do it.
This discussion about whether or not the "Elm community" will be meanies is missing the point and inventing a hypothetical scenario where you get kicked out of some club. Kind of a weird conjecture to me. I guarantee nobody truly cares that you fork Elm. The thing is that generally people who threaten to fork Elm are quite hostile on the Elm forums and subreddit.
If you fork Elm, an already tiny ecosystem, you'll realize that the hard part is building the community, not adding your pet features.
Everyone who has threatened to fork Elm has realized this at the end of the day. It's also why people overlook the lack of their pet features: because ecosystem is far more important.
I don't understand your argument about ecosystem being far more important. People ceasing use of any of the tools necessarily removes them from the ecosystem and community. They have no reason to care about those things.
Definitely. At that point, they need to weigh the cost of migrating their existing project to a new platform, or to maintain the patches that will allow the old platform to have the flexibility they need.
It's important to remember that they aren't being removed from the Elm community - they can still use the packages, the compiler will still get updates they could presumably rebase their patches on.
> I guarantee nobody truly cares that you fork Elm.
The article cites a comment by one of the elm core maintainers where that maintainer says he is opposed to the author forking Elm, and will consider it an attack on Elm's goals if he does. So I think we can safely discard this conjecture.
> I guarantee nobody truly cares that you fork Elm.
One of my coworkers once edited the elm compiler to remove the native code restrictions, and placed it on NPM. Evan emailed him and asked him to take it down.
There may be more to the story that I don't know, but from what I know it sounds like Evan does care.
the last thing i want is to get into drama with developers of a project, so if my choices are to give up and leave or fork and face drama, then i'll give up and leave.
how that affects the Open Source status of a project is irrelevant, this is simply not a project that i could use, and thus for all intents and purposes, for me at least, it's a project that can't be forked.
If you fork quietly, you can avoid the drama. Just do your thing and don't respond to anyone (in any forum) who isn't reasonable and civil. Don't start drama, don't feed drama.
if i am happy to just quietly run my private patched version, sure. but that's not the point, because the claim is that for a good Open Source (or Free Software) project, it must be possible to go public, and once you do that, if the original developers are unsympathetic then drama is unavoidable.
there have been hostile forks in projects before, even those that eventually had a good ending. egcs for example.
i was part of such a forked project too. it wasn't meant to be hostile, and the drama was limited to the project leaders, but it happened, and feelings got hurt.
You dont even have to push anything forward. Example Redhat's compilation of code or "forked" by CentOS, who were providing just a little more freedom. We all know how that ended.
Just keep in sync with the main project, and keep the annoying/proprietary stuff out.
> You don't get to stay in the club.
Or you become the club. I think LibreOffice has more club going than Oracle's OOo.
The open-source ethos means welcoming the friendly competition that comes from a fork. Look at the grandparent's link for the attitude taken by awk and bash.
I’ve never used Elm, but that’s not how reasonable open source projects work. Red Hat maintains several rather divergent forks of Linux and they’re still in the club. I personally run a fork of Linux that I maintain, and I’m in the club. The only people who attract serious ire from the club are people who distribute out-of-tree modules that play poorly with the rest of the system. Even in that case, no one gets excommunicated, but the upstream kernel makes no particular effort to keep problematic modules working.
Agree. I'm gonna be honest and say I haven't finished the entire article so author might have elaborated further after, but I got a chill when reading the following passage:
> The second is that if you advertise something as Open Source, there is a common set of assumptions about what that means, some of which are explicit in accepted definitions of the term.
It seems the "common set of assumptions" is around that people can get involved and actually have impact on the direction of the project, but that's not at all included in the actual definition of open source. https://opensource.org/osd
And I'm starting to see this sentiment crop up more and more recently, where someone open sources something just to share the code, while people expect the maintainers/creators to fit their project to their worldview. I think this misconception is the source of many throwing a fit on GitHub in issues/PRs where the maintainers won't change something based on the user's views.
Open source is and should continue to be about that you are free to fork the code if you don't like the direction. Otherwise, assume nothing from others work they publish for you to use for free.
Edit: I continued reading and found bunch of more passages where the authors understanding of open source seems to be incorrect. Some examples:
> Bu I think this claim is increasingly hard to defend. For me, real Open Source goes beyond a LICENSE file.
> I’d like to see some kind of openness in the development process before I considered something to be Open Source
> It seems that Evan and the core team have forgotten that languages, especially Open Source ones, operate as platforms, and in these platforms contributions from other developers and reputation are critical.
> Fairness must be a central principle in any Open Source project
While I agree that these things are nice, they are in no way required to called a project Open Source. Open Source is strictly about the software that is under the license, not the community/company around it. The creator and maintainers are free to accept/deny any patches they feel like, and project should still be considered open source, as long as the _actual_ requirements of open source are followed.
> I continued reading and found bunch of more passages where the authors understanding of open source seems to be incorrect.
The author is one of the "core team" members of Django[0]. So, it is safe to say that whatever assumptions he has about open source is not a fantasy and cannot be compared line-by-line to a text book definition of open source.
> 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?
It doesn’t tell me which or his opinions he thinks are backed up by accepted definitions or what he considers an accepted definition. So no, it doesn’t tell us anything. It sounds more like a weasel word to get out of providing citations to back up his arguments.
> whatever assumptions he has about open source is not a fantasy
I no way am I going to accept anyone's opinion based on what project they are associated with. If Linus Torvalds says something about open source or free software, I'll read what he says and make my opinion based on what he is saying, not based on that he was the original creator of Linux.
Anything else is just appeal to authority and we would do much better in discussions if we didn't do that.
The terminology is irrelevant. If you have certain expectations from the open source communities (among the diversity of possibilities that are open source) the narrative of what happened (especially with regards to being considered persona non grata if you fork) are worth knowing about.
I'm not sure people saying this know that the author is one of the "core developers" of Django. It is safe to assume that his expectation of "open source" is not far-fetched at all.
While you may have a point, language developed with closed process and just the source published in one of the famous code hosting sites need not emphasize on having a "community"[0] if it is not really looking to hear things from the "community".
>> The second is that if you advertise something as Open Source, there is a common set of assumptions about what that means, some of which are explicit in accepted definitions of the term.
> It seems the "common set of assumptions" is around that people can get involved and actually have impact on the direction of the project, but that's not at all included in the actual definition of open source. https://opensource.org/osd
To add to that, the OP's argument seems to hinge on Elm "advertising" itself as open source. I don't see "open source" mentioned on https://elm-lang.org/ or anywhere else. I'm curious where the OP thinks Elm crossed the line from having an open source LICENSE file to "advertising" itself as open source.
If the answer is that an open source LICENSE file counts as "advertising" a project as open source, then why use the inflated language in the blog post? Why not say, "If you [release something with an open source license], there is a common set of assumptions about what that means, some of which are explicit in accepted definitions of the term?"
Also, explicit in which accepted definitions of the term? The OP seems to be stating that without linking to these accepted definitions that would back him up.
I find you're being needlessly formalistic here. The author is explaining where they are coming from. What their understanding and expectations in the open-source world are. This helps to understand their position. That initial part was intended (I guess) to make comments like yours redundant. Because that way we can understand what the author means without guessing about their usage of the term.
The article does not require you to share that definition. And haggling over the precise definition of open source does not change their argument one bit. You can say that you use a more restricted definition, and that is it.
> What their understanding and expectations in the open-source world are
Thanks for putting it like that, it's completely true and I agree. Many people have an understanding and expectation of Open Source that not even the definition of Open Source agrees with (https://opensource.org/osd), which is contributing to this problem. That was a bit of the point of my comment.
The article doesn't require anything, but in general, most people see OSI as the organization who stewards a lot of things around in the Open Source world. If people cannot even agree about the definition of Open Source, we're in for a real treat now when companies start to abuse it.
> You can say that you use a more restricted definition, and that is it.
Again, I'm not going by my own vision of Open Source (as the article's author does), I go by the Open Source Initiative's definition of open source, which again, you can read here: https://opensource.org/osd
The OSI definition is useful as a baseline. When people argue over what open-source means, I think they can mostly agree on that definition. On top of it we see frequent arguments over authors' responsibilities and appropriate stewardship.
Looks like I've accepted that it's a broad term used in a lot of contexts. So having somebody give their angle on it before using the term is already pretty good by my standards. But maybe I'm being too liberal here. What parts do you see people expecting in open-source that go against the OSI definition?
(I can't help but note that you and the author write Open Source with caps which does actually suggest there is a specific meaning.)
Part of the problem here is that he suggested forking (he used the word "patching") the compiler in another project, and one of the core maintainers of Elm jumped into the issue and said it felt like an attack on Elm itself.
That feels a bit silly - why make a project open source if you're going to get upset when someone forks it?
I don't agree with everything here. Open source really does mean that you just have all the code to rebuild the thing from scratch under the right sort of license. Open source doesn't mean anything else, like having access to design decisions.
That is acknowledged in the article. But the fact is that you can BE open source without doing the things that make open source WORK.
[...]
Elm users who are not happy should fork the code --- everything, including the ecosystem's dependencies on an ELM internet domain --- and maybe produce something that is completely self-contained. Software that relies on "phoning home" is a risk regardless of where that is hosted and whether the people are nasty or nice.
Why should unhappy Elm users do this instead of going to a language+environment that they don't have to fork to get something usable for them?
Leaving, even leaving with a long essay like this one, requires a lot less energy and commitment. And being in an environment where you can benefit from the future work of others is part of what makes open source work.
> Why should unhappy Elm users do this instead of going to a language+environment that they don't have to fork to get something usable for them?
Of course they can do that, but then they are not Elm users, which makes them off-topic to the question of what Elm users should do to move forward as Elm users.
> requires a lot less energy and commitment.
We don't actually know that for sure without looking at the size of someone's Elm code base.
Maybe some users also think that Elm is otherwise fantastic and want to stick with it.
For various reasons, changing tooling is not like changing what shampoo you use, except for some language-hopping butterflies who are experimenting with a new thing every week.
> > Why should unhappy Elm users do this instead of going to a language+environment that they don't have to fork to get something usable for them?
> Of course they can do that, but then they are not Elm users, which makes them off-topic to the question of what Elm users should do to move forward as Elm users.
The topic was someone saying in detail, "Here is why I have chosen not to be an Elm user, and why you shouldn't be either." Which means that the experience of people who are not committed to being Elm users is on topic.
> > requires a lot less energy and commitment.
> We don't actually know that for sure without looking at the size of someone's Elm code base.
Fair enough.
Of course in this case he says that he is walking away from an 8000 line project that can't upgrade to 0.19 because of the native code issue. So we know how much code he is talking about, and also know that a rewrite in a new language is simpler than trying to upgrade.
In this case maintaining a fork certainly exceeds the benefit of the project.
> Maybe some users also think that Elm is otherwise fantastic and want to stick with it.
I am sure that there are.
> For various reasons, changing tooling is not like changing what shampoo you use, except for some language-hopping butterflies who are experimenting with a new thing every week.
No, it is not.
However if you will have to make the change some day, then it is probably better to bite the bullet and accept the pain now rather than adding to it for a future date. And if the leadership problems described continues, it is clear that the Elm community is going to fall apart and any project in Elm will dead end.
Therefore if you are an established Elm user, you should be ready to accept that tooling change pain as a question of when, not if.
> The topic was someone saying in detail, "Here is why I have chosen not to be an Elm user, and why you shouldn't be either."
When someone is saying divisive things, I think it's important to be clear and precise about what they're actually saying. Some of the burden rests on themselves, and some of it rests on the commentators.
And so I think it's important to note here, that I don't think he said the "you shouldn't either" bit. He specifically denies saying it:
> I should also note “Your Mileage May Vary” etc. It would be entirely possible to use Elm and find it adequate for your needs, and therefore never bump into the things I hit very quickly.
I agree with you. The obvious, implicit motivation behind an article like this is to help other users make the same decision. Denying it only constitutes a reinforcing acknowledgement. It's just a rhetorical device. If someone says "I don't mean to be rude, but you're an ass", they in fact mean to be rude.
A good chunk of everything you hear and read revolves around people trying to get others to be like them and do as they do, implicitly so. (Another good chunk is made up of people justifying, explaining and defending themselves.)
> The obvious, implicit motivation behind an article like this is to help other users make the same decision.
This is not obvious to me. Why do you assume the motivation is "to help other users make the same decision" and not "to help other users make the decision that's right for them"? I promise you that some people have sometimes written with that motivation in mind. If any denial is taken as proof of guilt, how do you tell those people apart?
If you're using/contributing to a open source project that is famous for it's non-community development and BDFL leadership style, it should come as no surprise when that continues.
The call for "If you're not happy you should fork the code" comes because this is a explicit expectation of the Elm core team and Evan.
What does "open source work" really mean? Open Source talks strictly about the licensing and distribution of the code itself, not the community and everything around. It feels like everyone are having two conversations at the same time. Open source as we currently know it, is just about the code. Open communities (or whatever you want to call it) is a separate discussion, and not needed to "make open source work" as you just have to license your code in a specific way to be open source.
Then we can discuss what makes open communities around open source code work, but I think that's a separate thread.
If you're using/contributing to a open source project that is famous for it's non-community development and BDFL leadership style, it should come as no surprise when that continues.
That's pretty much the central thesis of the article. With detail and examples on exactly what the leadership problem is and why it causes challenges for users.
The call for "If you're not happy you should fork the code" comes because this is a explicit expectation of the Elm core team and Evan.
And yet any attempt to do so is described by them as knifing Elm in the back.
What does "open source work" really mean? Open Source talks strictly about the licensing and distribution of the code itself, not the community and everything around.
What I mean by "work" is that it leads to successful projects. By a variety of metrics for success.
It feels like everyone are having two conversations at the same time. Open source as we currently know it, is just about the code. Open communities (or whatever you want to call it) is a separate discussion, and not needed to "make open source work" as you just have to license your code in a specific way to be open source.
Then we can discuss what makes open communities around open source code work, but I think that's a separate thread.
You have it exactly backwards.
You are right that "what is open source" is a different discussion from "what makes open communities around open source work". But this is the appropriate place for the second conversation. And more specifically for discussion of what it is that the Elm leadership is doing that leads to failure, and what it is that users should or shouldn't do given that Elm is being so badly lead.
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.
> It's only a problem for the ones who misunderstand the model. It's not a problem, it's by design. It's explicitly setup so that Evan has the final say in everything.
The fact that they intended to do a stupid thing does not stop it from being a stupid thing.
The core development team of Elm is an echo chamber of smart people who only listen to each other. When they are working on problems in their area of shared expertise, they should be very effective. But when they step out of their shared expertise they are predictably both ineffective and have no way to discover their mistake.
In this case they know little about i18n and therefore are unable to take feedback from people who know how it works. And there is no way to get them to see their mistake. These faults, left unchecked, will undo all that they hope to accomplish.
> > What I mean by "work" is that it leads to successful projects. By a variety of metrics for success.
> I'm always interested in hearing what metrics people are using for "success", so do please list them so we can be on the same page.
That is a fair question. For me success means, "I can use this to solve my problem, and be able to trust that this is something that will be maintainable in the future."
There are different routes to being maintainable. The smaller it is and closer to my own expertise, the more I can be confident that I can maintain it myself. If it is complex and far from my expertise, I won't.
Maintaining a language someone else built is not exactly the kind of thing I want to do in maintenance. (This is from experience, not ignorance. At my last $job I did exactly that with an internal language. And that language was much less ambitious than Elm.)
> > You have it exactly backwards.
> The author is the one using "Open Source" in their article, not "open communities" or "open governance". I understand it can be confusing, but let's not change the meaning of already existing terms.
You are seriously going to let a quibble about terminology prevent you from understanding what the author clearly meant??
Now that you know what I think that the author meant, go back and re-read it to see if you think I am right. If I am, you can see that what I am talking about is on topic.
But since you want to open up the terminology issue, Open Source BEGAN as a marketing term for a particular software development philosophy BEFORE there was a settled definition for what open source software meant. To this point, one of the founding inspirations was http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral.... Furthermore the practices for how Elm is being developed are exactly against that philosophy. (ESR is an idiot in other ways, but that is a discussion for another time.)
That this started as a philosophy and not a mere licensing term is obvious in things like the free software community's response to the phrase. If you want to dive down that rabbit hole, read https://www.gnu.org/philosophy/open-source-misses-the-point..... (Written by the person most directly criticized in ESR's essay. Ironically, also the person who probably did the most to create the foundation that open source built upon.)
So you learned something today. You learned that, from its very inception, there has always been a lot more to the phrase "open source" than just a licensing definition.
> Open Source BEGAN as a marketing term for a particular software development philosophy BEFORE there was a settled definition for what open source software meant. To this point, one of the founding inspirations was http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral.... Furthermore the practices for how Elm is being developed are exactly against that philosophy.
If you're going to bring up the origins of "Open Source", the above is NOT CORRECT.
It began as a marketing term for "Free Software" principles, as it was realised the FSF marketing wasn't convincing people in corporate environments.
From Wikipedia (I think this is accurate):
>> Netscape's act prompted Raymond and others to look into how to bring free software principles and benefits to the commercial-software industry. They concluded that FSF's social activism was not appealing to companies like Netscape, and looked for a way to rebrand the free software movement to emphasize the business potential of the sharing of source code.[35]
Not as a marketing term for Bazaar principles, despite ESR's involvement in both around the same time. Obviously the Bazaar paper added significant inspiration to the movement and to many projects, and informs some people's expectations around Open Source. But I have heard ESR talk about the origins of "Open Source" and it was quite clearly because "Free Software" wasn't getting the message across; the latter was too ethics focused for the corporates.
Btw, you can have Open Source without a Bazaar, and you can have Bazaar-style development without Open Source too (a lot of companies do so without giving it that name).
I'm describing how I experienced it as a young developer at the time. It was a weird combination.
Note in particular that a lot of people who jumped on the open source bandwagon were people who wrote some free software but did NOT want to only write free software. And there was a lot of messaging around social norms for how projects worked, why open source made sense, and how to do well by it.
But "if they all got together" is waving away the difficulty of getting them all together, cooperating, and working together. Open source projects are a lot more difficult to run than you might expect.
> Open source projects are a lot more difficult to run than you might expect.
Indeed. You pour thousands of hours of work into something and give it to the world for free, only to be met by “give us synchronous IO or we will throw our toys out of the pram!”
That specific example would just be laughable. "I gave you awesome asynchronous I/O; just write the five lines of code around a semaphore if you want it synchronous."
I am sure this moment is coming when somebody creates a fork and gets rid off the artificial hypocritical limitations imposed by the current core team.
And if it worked, they either A) split the userbase in half and make Elm LESS likely to be useful or B) get most of the userbase and make Elm totally irrelevant.
Forking a language isn't like forking a tool. Forking gcc doesn't make C any better or worse. Forking C (if you could) would make the C worse.
It doesn't actually make sense to fork Elm. There are pretty good general-purpose languages already which offer a superset of Elm's (the language) functionality. I think all of them already have Elm-like implementations available as libraries. In fact there's at least one migration tool that helps convert away from Elm: https://github.com/darklang/philip2
Choosing to hard-fork Elm and create lots of internet drama just doesn't make sense compared to moving to one of the above.
quoting: "And a further consequence of this is that non-English developers and end users are discriminated against, due to the difficulty of formatting numbers and dates in correct ways for non-English locales."
The issue seems to be hypocrisy of the Core team and not that it isn't true open source. Forking a language is suitable only for extraordinarily situations, Elm language might be good but ultimately it's not that extraordinarily good.
> Open source really does mean that you just have all the code to rebuild the thing from scratch under the right sort of license. Open source doesn't mean anything else, like having access to design decisions.
Open source means you have access to the source in the preferred form for making modifications (and not e.g. dumps of generated code). IMO that should include any design documents that the original maintainers would consult when making modifications themselves.
This post resonates with me. I'm not deeply involved in Elm, I just have an Elm side project (started on 0.17) with roughly 1k lines of code.
Do I love Elm? Yes, definitely. It's such a well-designed language. Lots of thought went into it. It's very focused and has great (albeit sometimes non-obvious) solutions for almost everything.
However, the leadership style is also what keeps me from recommending Elm to anyone wanting to create a project that cannot be simply rewritten in case Elm does a change that doesn't work for you. I wouldn't use Elm at work, since it would be a very high-risk situation. (In fact, I was faced with that decision and decided against Elm.) If you face a blocker, you're screwed.
A version of Elm that is being developed in the open, where people are allowed to make suggestions, where all feedback is considered valuable, where people can experiment and explore the design space without artificial limits? Yep, I would love such a thing, and I'd happily contribute.
Until that happens, I'll happily use Elm for small, personal low-risk projects. I do hope that the situation will improve once the "big rewrite" with a WASM backend is done.
This kind of leadership gave us Go. It's not necessarily bad. If everyone gets their way with the language specs, then all languages will look like a weird dialect of C++ :)
Same with Clojure, where Rich and other core contributors decide for the rest of the community what should be worked on. I think Python is/used to be the same.
Name of this leadership style is BDFL (Benevolent dictator for life) and seems to work for some projects, but you always have people feeling unfairly treated by it, while others enjoy it greatly. Guess that's the effect of being a human :)
Except those BDFLs give you escape hatches to do whatever you want. Elm removed it. It's the same as Clojure, if they didn't let you use your own Java libraries. Or if you couldn't write C extensions for Python. Rich Hickey isn't going to chastise you for resorting to a Java library if you have to, because despite Clojure being an opinionated language, at the end of the day he's pragmatic, which is why Java interop is so readily available.
But that's the point. The community close to the core team is toxic, according to this post. So, there are incentives for the rest of the community to fork the project and have it their own way. There is no need to be in good terms with the core team.
Oh please, maybe if all you're doing is reading hackernews articles. The language hasn't really changed that much in the last few years. The only major feature is async/await.
Rust is a complicated language and still has a very long journey ahead to prove its worth, I have yet to see it being used extensively in Mozilla to re-write Firefox which hasn't happened yet (may not happen as replacing C++ with Rust is a nightmare given most useful systems code is still either C or C++).
Hopefully zig [1], picks up. It's compiled code is smaller and better in performance compared to Rust and also provides a mechanism to write safe code with allocator choices. Also the overall zig language design fits in brain as the grammar is not complex unlike Rust which has a steep and complex learning curve. Rust developer spend a lot of time learning language feature and fighting with borrow checker syntax and still need to rely on unsafe C library to do anything useful. Zig made a conscious choice to make it work with C and realize it needs to work with C rather than replace it unlike Rust which is relying on C and still trying to proclaim as C replacement, when its not yet ready.
You shouldn’t take your opinions on things from HN discussions that claim that Rust is changing quickly, and then are only able to point out 3 things over 5 years that have changed.
I don't. Crate authors seems to be playing catch up to, or more likely, abandon their old work. I'ts really hard coming in to Rust to get a feel for what to use in any given situation as the crates are either dead or in alpha.
There are a ton of Go features that have been asked for by the community that have taken years to get mainlined. I think the most common examples are generics and package management. The authors of the language tended, at points, to be at odds with the desires of many in the community.
Even in those areas, however, Go hasn't done the things that Elm did (according to this article).
There have been a lot of experiments with Go package management, and some did get fairly widespread adoption. After many years, they are getting replaced with an official way, and there are some hard feelings, but experimentation and adoption of alternate solutions was never forbidden. Even with the official system, you aren't locked into the official package management infrastructure; there are flags and environmental variables you can set to use your own servers.
There have also been a lot of experiments with Go generics, often implemented via a preprocessor. I don't think any of these got a lot of traction, but again, they weren't forbidden.
Ultimately, the Go team decides based on what they think is right, but at the same time they aren't so insecure about competition that they need to suppress it.
Maybe, but the Go authors never banned people expressing disagreement or people forking the compiler or the tools.
Almost all programming languages have features being asked by the community and not available as soon as one would hope. Modules in C++. Value types in Java. Removing the GIL in Python. Parallelism in OCaml. Higher kinded types in Rust. Etc.
And most of the time there are pros and cons to adding these features or not, which sometimes evolve in a debate fracturing the community. It even happened to the otherwise peaceful Python community with Guido quitting after the decision of assignment expression: “Now that PEP 572 is done, I don’t ever want to have to fight so hard for a PEP and find that so many people despise my decisions.”
As far as I'm aware there are no features in go that are both fully implemented under a "for me and not for thee" compiler level guard. It's true that end users cannot have generics -- they are reserved for map, slice, array and chan. But that's not because the go team are hypocrites. They just dont have a general solution for generics yet.
> where people are allowed to make suggestions, where all feedback is considered valuable, where people can experiment and explore the design space without artificial limits?
Can you put your finger on each of those and why you think they exist? The only one that makes sense to me is the last one if that means, that people can use hacks and use private apis they were never supposed to use?
I‘m not sure why this hasn’t been mentioned by anyone: If you’re unhappy with Elm‘s constraints the obvious solution is to switch to PureScript (purescript.org). It’s basically are more powerful Elm like language with a great FFI and absolutely no constraints how to work with JavaScript. There are also a lot of compatibility packages to provide functions and workflows from the Elm ecosystem.
Do you think it is harder to learn than Ocaml/ReasonML though?
I think there is a good free introductory book [1], a welcoming community [2], the language and ecosystem are quite stable nowadays and there's good tooling (now that there's the Spago package manager).
It's definitely harder. I have been doing O'caml for about 20 years now, and we have probably one of the largest Elm apps out there. I looked at Purescript, especially because it also compiles to other languages (C++, BEAM) but the learning curve is a bit steep.
Not only is it nearly as high as Haskell, the PureScript guide hasn't been updated in years and is wildly out of date. You have to go searching for an unofficial rewrite, and those are incomplete as well.
Nope, not the same. You still need to learn how PureScript does things.
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.
It is, but the community is pretty awesome and helpful, and anyone who knows Elm and takes the time to read at least one introductory Haskell book should be able to get productive pretty quickly.
Still lost many hours for asking and debugging, if it ever get answered. Companies don't care, business don't care. They care about shipping feature, easy to find developers. Try explaining that to your PM or boss. In the end money talks.
I think using Elm, PureScript, or any technology that has a community orders of magnitude smaller than well established safer alternatives would be a dubious decision. I never advocated bringing either into a professional environment. I simply stated that there is a viable alternative if someone is looking to play in the space.
PureScript is wonderful. But it's a very steep learning curve if you don't already know Haskell, and the documentation tends to lag quite a bit behind the language.
The problem is that Elm's crowning achievement is that it took a lot of ideas from functional programming and produced an end product that is stunningly simple and easy to use -- even simpler and easier than most non-functional languages. Speaking as an avid Haskeller who revels in the arcane and abstract, PureScript is just another inaccessible and alien functional language that most people will be immediately turned off by. It's not at all a replacement for what Elm achieved.
Arrogant is the most accurate word to describe Elm and its leadership. I tried to use Elm in production between 0.14 and 0.18 versions and it was fun and mind expanding experience. I'm truly grateful that I've used it because it introduced a lot of functional stuff to me. But I no longer use it myself or recommend it for any serious work.
Breaking changes were negligible in the beginning. But I got fed up with rewriting the app after the 3rd Elm upgrade. I think it's irresponsible to advertise the language to be used in production and break it every fucking year. Speeches about finding the perfect solution are great for academical discussions and toy languages, but you can't just remove the stuff that your community uses without offering any alternative. It all stems from the arrogance and cult-like behavior of the core team. I'm sure that they're wonderful and very smart people who do their best to create the best version of the language that they can. But their management style is too dictatorial and they don't respect their community.
For me, the split started with elm formatter discussion on github. I disagreed with some of decisions that the core devs made and I wanted to see what other developers have been saying about it. On of the issues was the preference for 4-space indentations instead of 2-space. I understand that it's important to have a single source of formatting for the language. But at that time there was no consensus on what amount of spaces to use. Basically, the community divided almost 50/50 between the two. Moreover, a lot of core libraries and example code still used 2-space indentation. (that's why I preferred it). Due to lack of consensus, there was a suggestion to add a flag to formatter to set the indentation. It required to change some parts of code to pass the flag to the formatting module. At that moment, one of the core devs stepped up and closed the discussion because he didn't approve of this decision and he just said that 2-space people should adapt to the new 4-space default (that wasn't supported by any majority). It was the first time when I felt that the Elm management is too strict and I don't want to have anything to do with people with such attitude.
Yep! If people used tabs, then everyone can display it how they like and these stupid discussions wouldn’t be necessary. Alas, for some reason the world has rallied behind spaces. Sigh.
My editor maintains it automatically, so it is never wrong. There is nothing to check.
I'm sure there is a command-line pre-commit formatter I could use. But I have never tried to set it up, since I can reformat existing code with a couple of keystrokes in my editor.
Ok, but if you get "\t[space][space][space][space]", how do you know this wasn't supposed to be "\t\t"? That is, how do you know trailing spaces are for alignment and not for indentation?
A code formatter knows, so your editor and other tools can also know.
Most editors have code structure parsing of some kind built-in for tabbing already. E.g. pressing the <tab> key indents the current line to match the structure of surrounding code (or cycles between valid indents for something like Haskell or Python). So they know the difference between initial indentation (that people want to be able to configure visually) and alignment.
It doesn't really solve the problem. How do you format this code with tabs:
<TAB><TAB>function name(arg1, arg2,
<TABs or spaces?????> arg3 <-- align with arg1)
The other issue is with maximum line length. If you have a maximum line length of 80, do tabs count as 2 spaces, 4 spaces, or 8 spaces towards meeting that line length?
Using spaces ensures that it at least looks consistent, independent of your tabstop settings.
Not the person you're responding to but I do, or actually spacemacs does. The sequence would be $ -> J -> i -> ENTER -> ESC and I guess it's muscle memory.
I agree that this kind of indentation might not make sense on a collaborative project because different people have different standards, but if I'm the only one working on a piece of code I really think precise alignment makes the code a lot more readable.
I don't actually personally do this kind of alignment, but it was the easiest example for me to come up with to illustrate the problem of needing to align text on different lines.
You learn to live without precisely aligned arguments!
Really this is a peculiar kind of OCD. You don't need to have arg3 precisely lined up with arg1. Or better yet, indent all the arguments in a nice column - if there's so many that they can't fit horizontally, render them vertically. Most IDEs default to two indentations for continuation.
I've had some discussions with folks on projects who are very... focused on linting and formatting rules. They've reformatted my code in the past, and have insisted on blocking code that doesn't pass all their listing rules.
Them: "We have to use these tools to avoid disagreements about spacing and formatting choices".
Me: "But... I wasn't having any in the first place. It's only the 3 of you that were having these disagreements. And now you're spending ridiculous time planning reformat of entire codebase, instead of actually... moving the project forward.
Please don't bitch about me using $x = new Temp(); in a test file. I'm the only person on the project even making test files, and you're blocking my TEST file because you don't like variable name style..."
They got in to a quandary when trying to inline some JS in to a PHP view file. The PHP standard is 4 spaces, and the person doing some of the JS had defined 2 spaces for JS ("so we can all agree on it") and ... all hell broke loose trying to determine what the style/formatting should be for JS-inside-PHP files. 4 spaces? 2 spaces?
In elm you'd do one of two things: keep all the arguments on one line, or put each on its own line. At least, according to the formatter's opinion (which is honestly so nice to use when it just snaps everything into place every time you hit cmd-s). Of course, this convention is violated all the time when listing all the public exports of a package (with good reason IMHO; it lets your group similar things onto lines together) so it's not much of a convention: https://github.com/rundis/elm-bootstrap/commit/e412efe628854...
Indent with tabs, align with spaces. Alignment never follows any "N number of spaces" style guide, since by definition its to align with something else.
since we were talking about indention, not alignment, I don't see how anything changes. If I want my indent to be 3 spaces and you want 8, we can set our tab width and arg3 will still be aligned correctly for both of us.
Or you live with misaligned arguments (its a bit of a smell imho to have so many arguments that you need to split them over many lines, although it for sure does happen) and just use tabs for both.
My main point is that with tab, each individual has some control over their preferences, even if not perfect for alignment, while with spaces everyone has to live with the standard and nobody has control over their preference. That is, tabs is "mostly people get what they want", spaces is "nobody gets what they want unless they happen to want the style guide imposed on them". The former seems a lot better to me!
My main objection to using tabs has always been that the Tab key is heavily overloaded: it navigates (one Tab press to move the cursor to the correct indentation point), selects (tab completion), and it puts a variable-width character into my monospace-defined text file.
I'd rather drop the insertion part and have my editor handle adding an appropriate number of spaces.
Let me add this: there's actually nothing stopping you from displaying a four-space indented file as a two-space indented file. Just parse, replace indentation-dictated groups of four spaces with two spaces, you're done.
I don't know of a plugin that does this for $your-favorite-editor but it's, y'know, software. There's nothing which prevents it.
Wow, this is pretty damning. The author seems fairly level headed and the criticisms feel well reasoned. I've played around with elm a little bit, but this really puts a damper on my desire to dive in further. Hopefully the core team takes some of this criticism on board.
I've definitely found Elm worth playing around with - it's a really beautifully designed language with some really cool library design thrown in that I wish more people would learn from. That said I'd _really_ recommend steering clear of it for important stuff due to the issues described in this article.
I think people have already taken the good parts of Elm and implemented those ideas in other frameworks. Redux was inspired by the Elm, for example. I personally like using React, Redux, and Typescript. It's nowhere near the purity of Elm, but it's good enough.
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.
These posts (and HN comments) really make me wonder if adopters of fringe languages are always going to be thin-skinned developers who get emotional when they realize they won't be part of the language's design decisions. That "On Whose Authority" rant about Clojure complains about the exact same things. And I'll refer to Rich Hickey's response: https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au....
Elm in particular has this weird problem where there are vocal people in the community who you can count on to drape a wet, accusatory blanket over every discussion, and you wonder why they can't just find another language that they do like. Sometimes you need to leave the theater so other people can enjoy the show.
Also what are these languages yall are using where you're part of steering committee level decisions?
This blog post is full of the usual suspect complaints, like being annoyed that a language can use features like custom operators but they can't in their user lib even though most people would agree that user packages shouldn't be able to invent yet more custom operators. It's such a weird jealousy for a point to be "but core libs can do it, why not me? :(". Well, simple: think of the rest of us who don't want every user lib to define its own custom operators. But the complainer here gets hung up on what seems like an ego / entitlement issue.
>Well, simple: think of the rest of us who don't want every user lib to define its own custom operators.
Then why not simply not use those userlibs? Now it seems you're the one draping a blanket, only yours is over a non-specific hypothetical scenario rather than a real-world problem.
The reality is that people have opinions about things. You have opinions about things. People are going to try to manipulate tools they use because nobody in open-source has any significant amount of learned helplessness over software.
I think its a bit different with a language though. Because so much of other people's work is based on it, removing a feature that was being used causes all sorts of downstream chaos. Every time a language release breaks backwards compatibility it tends to really upset people, I think maintainers always need to be cognizent that their choices effect others.
They are. They might lose some users this way. They would definitely lose some users the other way though.
I suppose it must seem pretty strange to see a programming language built on a set of technical values, instead of trying to find the subset of most-popular values (because their real goal is popularity).
This can be a problem in Haskell, where you can find a library using some operator like +>>* that you haven't seen before, imported from one of its 30 odd globally addressed modules, which may just be re-exporting other modules.
Hoogle/google rarely help with such operators, so finding any documentation is often an exercise in frustration, scanning through library after library for one declaration.
How does Hoogle not help with such operators? Hoogle can search over all packages in the Stackage package set and can also be installed locally to look over all the dependencies of your project.
I'm not sure there's a meaningful difference between a strangely shaped operator and a strangely-shaped function. (Indeed they desugar to the same thing, except one is symbolic and one is alphanumeric).
Any decent library will describe the operator in its Haddock documentation, and most will export a named function with the exact same semantics and type.
It's a peculiar demographic I've noticed amongst people who have grown up with all their software available gratis or ad-supported.
"Oh this incredibly hard work that someone else did for free isn't exactly what I wanted and they refuse to change it the way I want for free"
If Elm is so great, and if it's 99% there, and you only need "this one little custom operator" added, or this "special piece of extension code" and it's really that 1% and you can't be bothered to contribute that 1%; to do it yourself, or pay someone to do it, well, then you deserve to use whatever piece of shit you end up with.
I've watched Elm since its inception when Evan was posting about his experimental FRP project on r/haskell. (Yep, Elm actually started as a functional reactive programming language. That was before The Elm Architecture was developed and all that terminology was thrown out.)
As the project has developed, I have certainly wished Evan had taken a different and more open approach to leadership. I think Elm could be 10x as big as it is right now if he had aggressively encouraged community involvement instead of trying to lock the language down so much.
That said, it's completely mystifying to me how Elm is surrounded in so much drama, and it seems implausible and unreasonable to attribute it all to Evan. In the early days, it started getting hate from some hardcore Haskellers who felt that it needed more sophisticated language constructs. They would have converted it into PureScript, which clearly has never gained any widespread traction either -- perhaps less so than Elm despite all the drama. This is probably one of the earliest sources of conflict where Evan went against what a vocal minority wanted. Since then, it seems to have just snowballed, with the Elm team getting more locked down and vocal users becoming more and more upset about not being involved.
At the end of the day I don't really know what to make of it. Elm would not be Elm if Evan had listened to all the aggressive requests to make Elm more like Haskell. It would still be stuck in FRP-land and 99% of web developers wouldn't be able to make heads or tails of it.
What I will say is this. I have written some internal tools in Elm, and it's one of the best languages I've ever used for web development. It's a revelation of what the web ecosystem could look and feel like in a parallel world. Years later, I would still pick Elm for such projects because nothing else comes close from certain perspectives. I can always go get the normal experience with TypeScript and React. Elm is what I choose for self-contained applications where I don't need and don't care to deal with all the general chaos of the web world. And, personally, I doubt Elm would be this way if the early naysayers had gotten what they wanted.
As someone who spent over a year working on a production Elm app, I agree with this post 100%. Our team experienced all of these issues and more.
The true cost of the approach Evan and the core team have taken is hard to measure, since what I observed most was skilled community members with the time and will to contribute silently abandoning the community after their efforts were roundly rejected or ignored. The record of these interactions tend to be scrubbed from GitHub and other community forums.
There are some really great ideas in Elm, but I would never recommend it to someone as a tool for production use. It is run more like a hobby project.
I (luckily) only implemented a few smaller projects in elm around the time of 0.18 release.
I started looking into how to get WebCrypto working, and was scared away by how they treated outside contributors. I liked Elm as a language, and Evan made a very good design. But to the core team, I got the message that they intend to work at their own pace, at their own leisure and will probably not take much input from outside contributors. This makes it very hard to expand the community and the usefulness of the language. They still have not afaik released anything for WebCrypto or WebWorkers. It is fine they are committed to the 100% pure language for frontend idea, but it makes it very hard to use if the Gods in the core team does not think it's fun/worthy to solve.
449 comments
[ 4.3 ms ] story [ 443 ms ] threadHard 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.
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.
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.
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.
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.
Has anyone considered making a compatible fork of Elm?
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.
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
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.
[0] - https://lukeplant.me.uk/personal.html
Why not? The OP claims that his opinions are explicitly mentioned in accepted definitions:
> some of which are explicit in accepted definitions of the term
If the OP is going to make that claim, why should we not expect to be able to find validation for his assumptions in a written definition of open source?
I no way am I going to accept anyone's opinion based on what project they are associated with. If Linus Torvalds says something about open source or free software, I'll read what he says and make my opinion based on what he is saying, not based on that he was the original creator of Linux.
Anything else is just appeal to authority and we would do much better in discussions if we didn't do that.
While you may have a point, language developed with closed process and just the source published in one of the famous code hosting sites need not emphasize on having a "community"[0] if it is not really looking to hear things from the "community".
[0] - https://elm-lang.org/community
> 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.
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 :)
https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
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.
[1] https://ziglang.org/
https://wiki.mozilla.org/Oxidation
they are continuing the work to replace the least performant/secure components in Rust when it's easily possible to switch them out
Code written for Rust 1.0 will most probably still work perfectly fine today.
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?
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
https://fulcro.fulcrologic.com/
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.
Using spaces ensures that it at least looks consistent, independent of your tabstop settings.
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.
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?
So in this case:
since we were talking about indention, not alignment, I don't see how anything changes. If I want my indent to be 3 spaces and you want 8, we can set our tab width and arg3 will still be aligned correctly for both of us.Or you live with misaligned arguments (its a bit of a smell imho to have so many arguments that you need to split them over many lines, although it for sure does happen) and just use tabs for both.
My main point is that with tab, each individual has some control over their preferences, even if not perfect for alignment, while with spaces everyone has to live with the standard and nobody has control over their preference. That is, tabs is "mostly people get what they want", spaces is "nobody gets what they want unless they happen to want the style guide imposed on them". The former seems a lot better to me!
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
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.
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.
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.
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.
As a completely random internet user evaluating what proglangs to look at next, I'm staying far, far away from elm itself.
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.
All Elm developers are equal, but some are more equal than others.