As a user of it I love Elm, keenly waiting for the next release, and enjoying myself greatly.
Obviously I’ve seen the various posts about the contributing situation. I’ve read them, considered them, and decided to trust the process, and see how it goes. As a user, I’m not looking to add the native modules and such that folks are keen for, so it’s not a big thing. I would prefer a more open approach, but I understand the arguments. (But this isn’t my point.)
The situation has got bad though. The bad vibes in the community have reached out such it’s now the dominant theme if you search for Elm.
The last few years I’ve been able to recommend Elm on client projects, and they’ve been keen for the choice. They’ve taken my recommendation, and it’s been a great success.
Now, despite no technical changes, I’ve had two projects in a row question whether Elm is a safe choice. Clients have clearly browsed a little and found the critiques of the project and the community. Even though I recommend it as a safer/easier solution than other options, that judgement isn’t passing muster.
It’s at that point that I really start to worry. For political reasons Elm starts to look as if it’s not viable.
Is there any statement or official repost to these arguments?
Is there anything that I can point clients to that says that’s Elm is a safe choice?
Is there any roadmap towards Elm becoming more open to contribution?
As one client put it, what happens to Elm if Evan falls under a bus?
As long as Elm is in its beta, this will probably not change. The reason for it is that Evan wants to try out different things and also allow breaking changes without needing to listen to the community. We have seen it happen with signals in 0.17. I believe this was for the better. So personally this does not necessarily need to be a bad thing.
There are a few people around Evan that are considered core contributors. I would assume that in that case one of them would take over.
As long it is not clear if Elm is actually “a safe choice”, there can’t be such thing. Also, is it a “safe choice” actually? What is to be considered “a safe choice” by most of the people? What actually is a “safe choice” objectively seen ? This might be interesting to think and write about, and promote Elm with, so that others can see: “Hey actually, this comes from the elm community, I have never thought of this”.
Most people look at these things very biased I guess. But I don’t want to put their concerns aside also. Managing fear is the “killer-app” !
I think you are not contributing to the doubts or justify them, but you are communicating to people in general. I think the other way would be ignoring it, and that might lead to more doubt. People are irrational and building trust is essential for any project and its community to grow.
I think it is fair to say that Elm has some risks associated with it. What is interesting is that those risks are quite different to the risks associated with other JS frameworks to which it might be compared. This makes the comparison not so simple, and I fell Elm is unfairly undervalued by many comparisons.
I would also claim that some of these risks are perceived risks, rather than serious ones.
For example, the risks around Elm are largely to do with things like:
Size of the project committer pool (bus factor).
Alpha status (version number < 1.0.0).
Functional Programming is less common than OO (hiring risk).
Package lock-in to GitHub (no private packages).
Some Web API features are hard to work with in Elm (content-editable, for example).
Slow release cycle (urgent bug fixes).
The risks around JS or JS frameworks might be things like:
Mutable code is harder to test and debug.
Npm trojan packages and other security risks.
Javascript is hard to refactor.
OO code can often evolve into incomprehesible spaghetti style.
Of the Elm risks I outlined above, I think the only one that is a serious risk is the slow pace of bug fixes. For example, imagine your company bet on Elm, but then found a show-stopper security flaw in a core package. It is possible to patch it locally, but not straightforward (actually, it is straightforward, just not documented or built-in to the system). It would be very frustrating to see such a patch languishing on GitHub. I do think any organisation using Elm for mission criticial projects should do its due diligence on this - learn how to build the Elm compiler locally, learn how to patch core packages locally. Its unlikely you will need to do these things, but you never know.
If you are evaluating the choice between Elm and JS + frameworks, you might like to conduct your own risk assessment? Have some sort of scoring system that values what risks are or are not important to you, and try to be objective about it.
I also think it would be a worthwhile exercise for the Elm community to create a list of these risks, and then consider what we can do about them. I am unlikely to have captured the full list above. Some are hard to solve without the BDFL cooperating, but some can be solved I feel.
I’m a little unclear on which specific things your clients are objecting to, but I’m assuming a big part of it is the possibility of breaking changes.
I’d point out to your client that breaking changes are always a possibility in every language and stack. For example, Elm is still sub-1.0 because the philosophy of the elm includes the idea that you only get one 1.0. Compare that to TypeScript, whose philosophy is that semantic versioning can get lost and they’ll break you when they want, so there.
As for what happens if Evan is suddenly unable to continue with the project (sorry Evan)–like many technologies, Elm isn’t just a personal project. There’s a corporate sponsor and a body of talent already familiar with Elm, and I think there’s already a fair amount of overlap between people who know FP and people who know how to write compilers because the ability to write very abstract things like compilers is one of the ways FP really sets itself apart from other types of programming.
It depends on how you view doubt I think. To me, doubt, insecurity, fear, and so on, all get multiplied by silence.
For example, if a disease spreads in your area, and people are getting sick, you want your government to acknowledge the problem, collect data, and so on, so you can do something about it. If the government does nothing, you end up with ad-hoc efforts, trustworthy and untrustworthy data being hard to tell apart, and so on. The narrative of “something is happening” is rolling either way, so it’s a matter of taking control of that narrative.
Of course, the Elm community isn’t hit by a disease, but I do think it is in something of a crisis. The narrative of “Elm is risky” is rolling, and we’ve got some ad-hoc efforts to try and fix it. But the community is set up so it’s difficult to answer questions about how Elm is doing, the plans for it, etc., unless you’re Evan (or at least a core team member).
I see posts like the OP as a way to try and get the narrative under control. Because right now it’s just feeding on the silence. @carltongibson could have stayed silent, but I don’t think that would have changed the direction the narrative is heading.
Wow, thanks all for the prompt replies. Lots of good points there.
Honestly, I don’t think that not talking about issue, for worry of spreading doubt would be sustainable or healthy. I think community self-censorship would be a really bad sign. However, my intention was to ask, I really did want feedback on this.
The issues my clients raise, they’d call Business Risk (rather than fear)
I don’t think it’s technical. Nothing has changed in that respect.
Previously though, making the case for Why Elm?, on technical grounds had been enough. (OK, yes, we’ll give it a try — it has to be worth it given churn in X)
But that’s one thing when the community is looking sane, and vibrant, and exciting. I think the issue is that now it (just trying to capture the sentiment the client expressed) looks like it’s going through some sort of meltdown. Is this really a healthy ecosystem we want to bet on?
My question is trying to find the correct way to respond to that. I found remaking the technical case failing to convince. OK, well, we’ll see is hardly resounding, and it’s a sea change from previously.
Would you work on a language where you spend 80% of the time debugging, where refactoring is a major pain, and where development proceeds at glacial pace instead of where you have “it compiles, it works” pace?
My intention wasn’t to be silent but instead of casting doubt, doing more of Elm at Rakuten - DEV Community. There’s a big difference between posting “elm doubt” or “elm dead?” and “elm success” or “elm wins!”.
Somehow there’s a disconnect between the posts like @lucamug’s and those of Luke’s. Luke’s shows up where people are searching while @lucamug’s don’t. Luke’s is an example of how small projects failed due to conflict of intereses, while @lucamug’s demonstrates years of success at an international company.
I feel like there’s something there that I’m struggling to communicate.
I’d try doing a side-by-side, point-by-point comparison with other tools. It’s easy (and understandable) to read the negative posts and get nervous. But a general “I don’t know about this” feeling is easier to talk about if you’re talking about other tools at the same time to compare. It’s a technique some places use to de-bias hiring processes — looking at a bunch of candidate resumes side-by-side instead of one after the other makes it harder for pre-existing biases to sneak into decision-making.
What are the other tools they’d like to consider? For example, if I were comparing Elm vs React, I might compare them like:
Refactoring: React code needs to be way more comprehensively tested to come close the level of refactoring safety Elm has. Big refactorings on big projects are (I would guess) potentially weeks or months of dev time difference in the time it can take to finish
Ecosystem: React’s ecosystem is way bigger, so it’s more likely you’ll find niche libraries for niche purposes, but with Elm’s there is often one clear and excellent library choice for a particular feature — less time spent having to do research
Pace of change: React and the React ecosystem change a lot, which can add cool new features, but can also break things. Libraries can become incompatible, older tools can stop working, etc. The slower pace of change in Elm means things are less likely to break unexpectedly, and the strictness means that when they do they’re likely to be easier to fix, but it also means sometimes specific issues take a while to be addressed
Substitute in whatever factors matter most to your client, and attach concrete numbers (even if they’re best-guess numbers, though of course be honest if you’re guessing) to whatever you can (e.g. the amount of money the increase in refactoring time would cost in React vs Elm, or on the other hand if there’s a library that you need in React that’s missing in Elm, how much extra time/money it might take to implement in-house in Elm). My guess is that this way of talking about it also means that if they decide to go with something else, you’ll all feel better about the hows and whys of that decision even if it doesn’t turn out to be Elm.
It also might help to share how your own experiences have informed your bias toward Elm. If you’ve had a lot of React projects get totally off-the-rails complicated such that everyone was afraid to change anything for fear of breaking stuff and had a lot of Elm projects of similar complexity go fine, that’s a contrast worth talking about.
Maybe, preferring Elm over everything else is by itself biased. How to explain “why Elm is better” if you are biased to it ? Also, it is not about technical things the OP mentioned … They are concerned about everything else except technicals it seems. I think there are lessons we can learn from this
I am working on Elm full time, the same as always. I am currently doing some exploratory compiler work that is relatively long term. I wrote about it here and the plans are still the same.
If someone has a security issue from the compiler or core libraries, please DM me about it. Outside of security issues, I think capacity for more discretionary changes will increase once the lessons from the compiler explorations become more clear.
Can the people who run the FAQ point to the post linked above for a “roadmap” question? I can put that content in an .md file somewhere if that helps. Please DM if you are making the FAQ edits and have questions about a draft or anything.
More Generally
I tried to talk about how expectations of “corporate open source” vs “independent open source” in this thread. It tries to “define the problem” of meeting the expectations that many people have for programming languages.
I will be talking about these kinds of topics here on Friday.
I was also scheduled to do a talk about this at Deconstruct conf in early 2020. It got cancelled, but I hope I can do something like that later in 2021.
I hope this information is helpful to a general reader, and I encourage you to DM if you have a decent amount of Elm code for your business and want to talk about something.
Maybe you could pour that on the elm blog also ? I think it is very important to have these kind of thinking processes and results of it summarized in the elm blog. It reflects greatly on the way the Elm Project works, for the general reader.
Hi Evan, it’s good that you can point to specific places for information, but I think we would all really benefit from a clear, single source of truth on how to understand what’s going on with Elm. I tried to capture some of what’s missing in my analysis here.
In my expierence, clients are primarily not interessted in technologies but in the outcome (faster redesign, less bugs, aso). But the OP specifically asked for advice for a client that is concerned with technology, so I think my post does not fit here.