Here is my attempt at de-duplicating and writing up this list of risks.
I have written each one from the point of view of a hypothetical person with decision making influence in some organization that is conteplating using Elm for its next project. This perspective might be a little different to the perspective of those who have contributed to this list, but that is the specific risk that I am trying to build a picture of. To answer the question, “How can Elm be de-risked?”, with the aim of trying to discover ways to actually achieve that.
Bearing this in mind, if you feel I have misrepresented what you were trying to say - please do suggest a correction.
-
The Elm project runs on a Benevelent Dictator For Life model, with only Evan merging commits into the compiler and core. Evan’s role is highly non-fungible in this. There is a risk to my business if this way of working fails, who will take over the poject? Will they do as good a job?
-
I don’t have a clear understanding of what Elm’s roadmap is? I am trying to forward plan and understand if Elm will continute to satisfy our needs in the future.
-
Elm has made breaking changes in the past and the community has had no voice in deciding or vetoing such changes. For example, removal of user defined operators, or preventing the compiler from building user defined kernel modules. Will these kinds of changes continue to be introduced in a similar manner going forward? Is it clear what I can safely rely on and expect to be supported through migration tools such as elm-upgrade?
-
The centralized package server can go down causing work outages at my organisation. There is no official support for offline working, or local package caches. The packages are all stored on GitHub, which can break things if they are renamed or deleted from there. These things are infrequent but out of my organisations control.
-
The Elm release cycle tends to be long, and focus on “getting it right” rather than “getting it right now”. It feels more risky to bet on something without a steady stream of updates.
-
Forking and patching core packages is not officialy supported. My concern is that if I hit critical bugs it may slow development down or derail it altogether, if my team cannot fix issues quickly themselves.
-
Elm does not appear to be growing rapidly and there may be a slight decline in interest. Will my team lose interest? or the Elm core team or community?
-
I have a perception that Elm packages are frequently abandoned - but no hard facts, or relevant comparison with abandonware rates in other eco-systems. Sometimes Elm packages have been slow to be upgraded to newer versions of Elm. Will abandoned packages cause problems for my development team? Or will the permissive licensing, availability of all source code on GitHub and a fork and fix if needed approach work well?
-
Elm is has a smaller following than the alternatives that it most easily compares to, such as React or Vue. Will the smaller tallent pool make hiring more difficult?
-
There are a lot of open GitHub issues, is this a sign that resolving issues is more difficult and time consuming that I can reasonably expect it to be?
-
Some APIs (for the web or otherwise) may be difficult to support in Elms programming model OR it is not clear if they should be part of its kernel or left to the programmer to implement with ports or web components. Some examples are WebSockets, WebRTC, content editable, audio, video and WebGL. If I need these APIs now or am likely to need them in the future, I need to carefully consider what my approach to using them will be, or there is a risk of becoming blocked or sinking too much time into R&D around these APIs. elm-explorations/elm-webgl and elm-explorations/elm-test both look like very important packages for the APIs they form the core of, but they reside in an ‘explorations’ project, and appear to be risky bets.
-
There is a cultural difference between Functional Programming and Object Oriented Programming. Will introducing an FP language into my organisation cause a distracting culture war? Will my developers love this language and adapt to it quickly and be productive using it?
-
Elm developers cannot write their own kernel code with direct FFI into Javascript without jail breaking the compiler. Also compiled Elm code cannot easily be called directly from Javascript. I feel that my developers must be able to do these things.
-
Some algorithms rely on mutation to be more performant. This could mean having to write parts of my application outside of Elm, using ports for example.
-
The current Elm version number is 0.19.1 indiciating it is in alpha status. It is hard to justify using an alpha status project in my organisation and the version number rightly or wrongly stands in the way of Elm being adopted by my organisation.
-
Elm does not have native mobile support, only web apps. My business may need a native mobile app, even if we start out with a web app built for mobile.
-
Is the Elm project alive? I find it hard to tell without frequent updates and seeing recent commits in elm/compiler? Rightly or wrongly my organisation is put off by its lack of a constant buzz of activity.
-
I have a perception that Elm is a hard project to influence. Incremental fixes do not fit the BDFLs working style. Potential contributors are put off by their sense of a lack of involvement. Could this lead to a poor relationship between my organisation and Elm that is detrimental to my project?
-
Some aspects of the core CLI tooling feels a little unfinished, specifically the ability to upgrade or remove packages - though I understand this is fixed in the third party elm-json tool.
-
Elm does not have big commercial sponsors like React and Angular do. Its not giving me a cozy ‘too big to fail’ feeling.
======================================
Bus Factor
Elm would have a (near-)death experience if Evan ever just got sick of it and turned off packages.elm.org 3
======================================
Unclear future direction of the language and it’s features
Missing transparent roadmap. I don’t care if it will take a year or two or even if half of the features will be dropped, but most users would like to know what is happening. I imagine that this is the main reason people from outside think Elm is dead. The last roadmap was not clear enough what was the potencial explorations. Including that last site blog post was on 21 Oct 2019.
This may be outside the box you’re targeting, but I think there’s a meta-risk that Evan’s goals are not necessarily yours.
Yes, one metric of success for Elm is how many users it has. But there are others that might be more important to Evan. I’m not Evan, and I don’t know his goals, but…
Consider: Rust’s error messages are really nice. They are nice because Rust people saw Elm error messages. Elm set a bar. Other languages have also started striving for high-quality error messages. So the influence of Elm extends well beyond the Elm user community, and could easily outlast the language.
======================================
if I would like to build my business on the language, I need to be sure that new version of the language won’t remove something I’m going to rely on (like e.g. Lazy structures, Kernel modules etc.) - without any roadmap or communication in advance we are just blind 
I think the community has an image problem, that also adds to the risk. When 0.19 was released and native code access was removed, there was very little empathy for the people who got burnt in that transition. It was common to hear a phrase ala “Your goals don’t align with Elm, have you considered another language?”, regardless of how much Elm code somebody now had to migrate.
I think that transition was damaging, because it created an image of a project that might change direction, and if your project doesn’t work with the new direction, you’re shit out of luck. Taken with the closed nature of Elm’s development, and your inability to influence its direction, I think this is perceived as a risk.
Whether that image is accurate or not is out of scope here, but it was an impression I got back then, and I doubt I’m the only one.
======================================
Relying on one central packages server
Package lock-in to GitHub (no private packages).
======================================
Slow pace of bug fixes
Slow release cycle (urgent bug fixes.)
Some small chance of hitting a show stopper issue and then nobody addressing that for years.
======================================
The inability to run forked versions of core libraries (and the idea that a new version of Elm could make it even harder to get around this limitation. For all we know, such a release may be made before the relevant bug fixes are put out).
(This would be much smaller if bug fixes were released in a more timely manner)
If you’re using React, Angular, or Vue, it’s in the context of JavaScript. If you need to fix a bug in one of them with a local fork, you fix it in JavaScript. JSX notwithstanding, it’s all basically one language at bottom. If you use Elm, now you’re using Elm and (probably, via ports) JavaScript. And if you need to fix a bug in Elm with a local fork, you’re adding Haskell. Three languages!
Speaking of which, setting up a local fork of Elm where you can fix bugs (and manage private packages) is not supported or documented.
======================================
Perception of a shrinking community
Will this perception frustrate core team making the ecosystem be abandoned as a whole?
======================================
Will I be able to hire?
I think for managers/companies the most important thing is: can I found the skills in the market?
They are used to quickly changing technology, but if they think they can’t hire people to work on a project after you’re gone, it’s usually a non-starter.
Functional Programming is less common than OO (hiring risk).
======================================
Will packages be abandoned frequently?
Strict version control causes packages to be incompatible with newer elm versions even if they are compatible (unless maintainer takes action)
I’m fully aware of the benefits but if the perception is that community/maintainers are leaving - how will the ecosystem keep up with the core if even the stable packages will at some point be considered outdated?
======================================
Brittle packages - renaming the packages/repository breaks the build (i.e. Skinney → robinheghan rename)
======================================
Unclear process for raising issues. GitHub issues look like they can end up never getting responses, and it’s common to hear that you should submit experience reports, but it’s not clear where they are best submitted.
======================================
Perceived difficulty in implementing unsupported API-s (some common some more exotic)
Will I be able to easily support WebSocket (ports)
Will I be able to easily support WebRTC (ports + custom elements)
(these are the two that come to mind first)
The perceived risk is not whether this can be done but more how will it work and what are the long - term consequences as opposed to using technologies that have an established best practice and library support.
Missing library.
Some libraries lend themselves well to ports/webcomponents, but in other cases the integration needs to be deeper and so a significant part of the application then needs to be written in the JS side. Such code tends to be worse than just writing it in JS-native tech, especially if particular care isn’t used in the design.
Writing the library in Elm may be impossible or infeasible.
Some Web API features are hard to work with in Elm (content-editable, for example).
======================================
Elm is very different from its peers, which can make it unattractive to developers
Developers may not like that they have to unlearn many habits, like how to build components, OO structures, etc.
Knowledge built up around various languages, libraries, and frontend frameworks doesn’t carry over to Elm, potentially feeling like a setback to some
Developers may prefer a framework and language they consider to give them higher value in the job market
FP is significantltly different to OO. That can set up a cultural war in team or org if not completely bought into.
======================================
Lack of direct JavaScript FFI. This 21 explains why it’s a risk in the part where it mentions elm-explorations/markdown
To expand on the lack of a FFI, yes, it means that it’s difficult to call existing, pure Javascript code. But it goes the other way too:
Only Elm code can call other Elm code, so if you buy into writing Elm code and end up regretting, it’s hard to move away again. You’ll have to try and break your Elm code into isolated islands, that can be migrated one by one.
======================================
If you need to write an algorithm that needs mutation to be performant, you have to use Javascript and ports
======================================
Top one (by far) has been not having a v1.0 release yet. Not having to justify the whole development philosophy behind Elm and its version numbers would have been a great help. Managers already start with a bad impression, which poisons the whole conversation.
Alpha status (version number < 1.0.0).
======================================
Browser lock-in.
If I make a great game with Elm, I can’t release it on e.g. iPhone or Nintendo Switch (app store). I can make it somewhat usable on a mobile browser, but then it’s a compromised experience. I would have to re-write the game in Rust or some other language that cross-compiles into native code and supports multiple graphic layers (Vulkan, Metal and so on).
Counter: Elm can be a good prototyping platform for games, and the “Rust rewrite” can be a good chance to review decisions made in the prototype.
======================================
Perception of unsupported platform: There are bug reports that are years old, nobody addresses them.
======================================
Unwelcoming attitude towards people that want to fix these things. PRs are unreviewed.
Hard to influence. A big company need contributors on the inside to guarantee their needs. Small companies need the reassurance that big companies can do this. (Works both ways though, small companies can be screwed over by big ones by the same set up).
Elm has a word-of-mouth problem in part because it can be particularly frustrating for would-be contributors, and there doesn’t seem to be much effort put into expectations-management in that regard. Many developers are used to making small contributions to open source projects, especially bug fixes. It creates a sense of security when those get used – or even if they get rewritten to fix the bug in a different way – because the bug goes away, and a sense of community because you were responsible for helping make that bug go away. With Elm, there is no way for someone to commit a small amount of time or money to solve small problems in or near core. There is no mechanism for triage of externally-contributed bug fixes and so forth. So people who would like to contribute, and who have solutions to things that are problems for them and probably others, have no outlet for that intended generosity. This is a broader problem in Open Source projects – a popular project trying to keep up with all the bug reports can look like Lucy and Ethel in the chocolate factory – but the lack of attention to the emotional impact on the developer community leads to feelings of rejection. (While I’m here, I’ll plug the book “Working in Public” which covers this topic in depth.)
======================================
CLI for managing packages lacks basic functionality such as removing or upgrading packages. It was the first thing that myself and other people I know stumbled upon that made the toolkit look “unfinished”.
The elm-lang website could use some love. The news page has very sparse updates, which are also old by now. It creates a bad first impression on people assessing how vibrant the community is.
======================================
Elm doesn’t have big corporate sponsors. React has FaceBook, Angular has Google, Vue was Alibaba for awhile IIRC…
======================================
