Elm - What are the risks?

Hi all,

just wanted to say it here. I was struggling with this and that around Elm, its future, frustrations, and must say at least as seen from far (my perspective, and reading others thoughts)… lack of communication with the community. I see all the pluses or majority of them, but I can see a lot of not so great things too.

After more than two years… I come to my peace for now… and I am leaving Elm and things around it… just because the light at the end of the tunnel is not seen so clearly.

Someday, perhaps… when “PR” around Elm will be better so that I will know more clearly what to expect and for how long… and when I won’t have the feeling anymore that this is …as someone said the other day… private project put to public to use it.

All the best Elm.

Bye

2 Likes

One comment on packages. There is elm-json which I use frequently. Here is elm-json --help reports:

SUBCOMMANDS:
    help         Prints this message or the help of the given subcommand(s)
    install      Install a package
    new          Create a new elm.json file
    tree         List entire dependency graph as a tree
    uninstall    Uninstall a package
    upgrade      Bring your dependencies up to date

One installs it with npm.

3 Likes

Last time I tried it, I think the upgrade and uninstall commands were not implemented yet. But I just tried it now, and they are.

So that means that this is an easily solved risk, although not having this implemented in the main elm compiler CLI still leaves that impression.

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

  • Elm would have a (near-)death experience if Evan ever just got sick of it and turned off packages.elm.org

  • Elm doesn’t have big corporate sponsors. React has FaceBook, Angular has Google, Vue was Alibaba for awhile IIRC…

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

5 Likes

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.

Consider: the impact of TEA on React/Redux.

Consider: the number of “Elm-like” libraries written for non-Elm contexts. In Rust, there’s Yew and Seed, for instance.

(Another person on Slack noted that Elm’s impact extends to Reason as well as frameworks from megavendors like Apple and Microsoft.)

Innovation and influence might be way more important than “how many users does Elm have”?

So if the things that make Elm really important are the things that make it really different and better, and those things then virally infect other languages and take off — is it really important if there are unfixed bugs? Would the world be a better place with worse Elm error messages but more Elm users? I don’t actually think so.

Which is not to say that as someone who would enjoys using Elm for work, there aren’t things that frustrate me – but I’m quite happy if Evan ignores String bugs and keeps spending time on “stuff nobody’s done before", which to the extent that action is the true statement of preference, seems to be his intention.

12 Likes

Hi everybody!

Always great to see everyone so thoughtful about the future of Elm. <3

jhbrown, I think you are exactly on point. There is obviously a discrepancy between Evan’s goals and the goals of some other people in the community. There is nothing wrong with that, from either side! As I just wrote in another thread, everyone should have the freedom to pursue their vision, just as Evan does. I’d personally love to see a fork of Elm by another name, where we explore a different governance style. This is of course a lot of work, but the dream can come true if everyone does their part and there are obviously people with the passion for it here. I think that is the only way of truly seeing what a different governance will be like! It could fix the string bug and everyone could get their PR merged. It could keep up with the developments of Elm- or not, if it doesn’t fit the vision! I think this is the most productive path forward.

Once more, great to hear everyone’s thoughts- there obviously is plenty work to get started with!

9 Likes

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  20. 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 :frowning:

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…

======================================

11 Likes

Here is a rough draft of what the survey might look like. What do you think?

Does anyone have a suggestion of a survey tool to use? Does not need to be super fancy, something that is easy to set up and extract the results from would be my preference.

Draft of the survey:

Opening Page

Paragraph explaining what this survey is about.

Are you able to tell us something about yourself and your professional work?

Job Title or Function:

Are you involved in making decisions on your organisations choice of technology stack?
Yes/No

Level of Elm experience:

  1. I have never used Elm.
  2. I am a beginner in Elm.
  3. I am profficient in Elm.
  4. I am an expert in Elm.

Does your organization use Elm?

  1. Yes, we currently use it.
  2. We used to use it, but changed to something else.
  3. We are currently considering using it.
  4. We have considered using it in the past, but decided against.

One Page for Each Risk, the order should be randomized.

How severe is this risk? Scale of 0 to 10.
0 I am not concerned about this at all.
10 This is a deal breaker for me.

Do you have an idea of how this risk can be reduced or eliminated?

If so, how much difficult do you think this would be to implement? Scale of 1 to 5.

  1. Its a small job, a days hacking, or a blog post to explain something better.
  2. Its a nice little project, easy and enjoyable to do.
  3. Its a more significant project AND can be tackled independantly. A significant third-party Elm tooling effort, for example.
  4. Its a lot of work OR needs coordination and buy-in from the Elm community.
  5. This is a huge project OR needs buy-in from the Elm core team.

(Notice I have conflated effort with coordination in the above scale. Should I split this into 2 separate questions?)

Do you have more information around this risk you would like to share? Personal experience, experience within a work environment, war stories from an Elm project and so on?

Closing Page

Did we miss any important risks? Please tell us about risks around choosing Elm for your next project that are not covered already by this survey?

6 Likes

Who is the intended target for this survey? Should people who use elm for personal projects which are not part of an organization fill it out?

I would include a question for the size of the organization.

Google Forms is free, easy to get data out of, and has worked well for me in the past. Typeform is pretty, but I’ve never actually used it.

3 Likes

As his wife and a fellow developer, I’m happy to take this one on lol

9 Likes

Isn’t Angular basically dead? Think this is a pretty false feeling of safety! If it’s any help, I can say that Evan and I have literally planned the next decade around the continued development of Elm :slight_smile:

10 Likes

I think if you are going to create a survey there are several things you need to include and be clear on yourself before sending it out:

  1. Who are the creators / owners of the survey. It needs to be clear this isn’t the work of folks who are core maintainers of the Elm project, and wasn’t requested by them

  2. What actions you the creators of the survey intend to take based on the answers. Will you create a fork? (If so, maybe better to frame the survey under the name of the fork) Are there specific tools you’re considering building?

  3. I agree with @terezka that it would be a good idea to also ask for specific examples where these issues have actually impacted folks

My primary concern is that this without a proper framing this survey will just create more work for Evan. If people get the idea it’s some sort of official communication, it will just create more misguided expectations and confusion outside of the community. Similarly if you’re not clear on the actions you plan to take as a result.

I recognize that there are good intentions here, but please be very careful in considering the possible unintended impact of your work, and setting expectations clearly.

I honestly don’t think this survey is a particularly good idea, because I expect it will leave Evan holding the bag in the end, but if you are intent on creating it, please at least do everything you can to prevent that outcome up front.

2 Likes

Sure, I’ll make sure it says its a survey that I am conducting independantly.

I think it would be helpful to get answers from anyone involved in Elm at any level - even if just a personal project someone might still be very familiar with many of these issues and have a view on them. I would also be encouraging people to try and get some answers from people who are involved in a more manegerial or technical influencing role that they may know or work with. Particularly in organizations that do use Elm, or chose not to.

1 Like

I am not trying to draw up a list of things that I think Evan should fix, nor do I have any expectation that he would, or would appreciate being given such a list. The things that interest me most, are the things that we can try and solve independantly.

I am working on my private package server, but have written a spec for it that describes the full extent of what it will be in its first incarnation. I want to understand more fully the problem that Elm has in interfacing into the world of professional work more widely and see if that informs my thinking around what direction I can push in towards that end. Also, the results may help inform others thinking around what they can do.

I find the N+1 conversation about this, where people pitch in with their ideas but nothing comes of it a little pointless, a distraction at best. Hence the reason for the risk based approach, which is analytical, and not just based on feelings, opinions or sounding off. Gather information - Analyze - Act.

My guess is this will confirm that some of the hardest issues to solve will remain unresolved - are they the most important issues though? And at the levels below that, there is some interesting stuff, that is fixable.

4 Likes

Thats wonderful, it gives me a warm fuzzy feeling all over.

6 Likes

I personally look forward to many years of working with Elm and to its future evolution. It has certainly changed my programming life for the better and enabled me to be far more productive.

I got started in software development with Angular and Ruby, and learned a lot with them. But among the positive lessons was another one: how difficult it can be to grow and maintain a large codebase: hours or days spent tracing runtime bugs back to the source, then fixing the source without breaking something else, etc. In Elm, runtime errors basically don’t exist, and the type system and compiler make refactoring it a pleasure, not an anxiety-producing ordeal.

I believe that the economic benefit of making easy code changes and refactoring in Elm is underappreciated. These tasks take time, and for business, time is money.

Good for you, and good for Evan!

11 Likes

I think a very good response to compiler closed, can’t call JavaScript directly, is that nobody has forked the compiler and created an alternative. It feels that won’t be much work (16 hours??) and can be used as plugin, and probably fairly easily maintained when incorporating new features.

Given that this hasn’t happened, it seems to me this indicates these features are not pressingly needed in the community. It’s more the it would be nice scenario.

3 Likes

I think it has happened, but the successes of these forks vary. The most popular fork I know of is this one:

1 Like

I knew about that one, but I thought it was proof of concept, not really in use, marketed or working.