Request: Elm 0.19.2: any update to help adoption to prove that Elm is not dead?

[rupert]

@Maldus512

The initial question is about promoting Elm to companies that aren’t already using it, so I was not taking into account compatibility with a previous codebase when I mentioned Gren. I can understand quite well that in your situation it doesn’t work this way.

Don’t forget that these new companies may be basing their decision based off experience reports from people who worked for the old companies. “Those old companies that used Elm got burned because it wasn’t maintained, then the Elm community shifted over to this new-shiny-thing with the same ownership model, so lets go with that because I am sure it will work out differently this time and there is no risk at all the same thing won’t just repeat itself.”

I agree its a bit depressing - or maybe boring might be the word. Software maintainance, yes its boring. Hard work too.

[ChristophP]

Hi @greglearns ,

I see your problem. I think I can relate because I share some things with you.

1. I was a huge Elm entusiast
2. I was evangelizing for it hard
3. I got increasingly frustrated about the failure to do 2).

Elm is such a well-made and tought-out piece of software, how can people not want to adopt that?
Turns out I learned, people are somewhat skeptical of new technologies that are different from the ones they know. That makes it hard enough to evangelize for Elm alone since many people don’t get the benefits at first that are obvious to the experienced user.
The lack of visibility and refusal to add some transparency and commitment to support users in an adequate way makes this nearly impossible to advocate for (the expection being teams that are already sold on functional programming and niche technologies IMO).

So my response would be pretty close to what @Maldus512 said.

I still enjoy using Elm for myself, but I wouldn’t recommend it in commercial settings anymore over something like React + TS unless something major changes about the way transparency, contribution and user support is handled. Not because I don’t think Elm is much nicer to build things with, but because if there’s a lack of trust that maintainers will drive the project in a way that is beneficial to people adopting it.

Even though that is probably not the answer were hoping to hear I hope that gives you some insight into my experience on the matter.

[dta]

@rupert

Yes, that was the starting point. But the language and core libraries have been modified in ways that make them not backwards compatible. So no good for the 150K LOC Elm codebase I am working on - there will be no simple conversion path to move from Elm to Gren.

Backwards incompatible does not necessarily mean difficult to convert. At this point, I think the conversion path would still be pretty straightforward (unless you use GLSL):

1. Write an elm-review rule that converts generated record constructors to explicit record syntax (I have no idea whether these rules already exist.)
2. Write an elm-review rule that converts tuples to records
3. You now have valid gren code

[lue-bird]

For 1: NoRecordAliasConstructor

[Atlewee]

You forgot that gren use array as default datastructure instead of list. So no cons :: operators allowed.
But I get the idea, converting elm code to gren is a simple/safe mechanical refactor done in hours, not weeks.

[thinhtranhnvn]

From my point of view, what Elm may really needs is to add up features like Type Class and declare it the version 1.0. The version numbering may give a kind of assurance message like “Fundamentally completed” and “Ready to be used” to new learners, especially someone who is new to coding.

The website looks nice and elegance already. The interface of the Elm homepage don’t have to change to notice old user because experienced coders often have strong subscription attitude towards coding news and communities.

What Elm may really need is a more complete set of functional features, so the advanced users may stay and nurture the community by giving supports to new learners and publishing packages to solve problems in particular business domains rather than to borrow missed features from Haskell or other advanced Functional languages.

Can small things like where binding syntax be added up, too? Since it give function definitions more declarative look. We don’t have to scan through the binding details first to get the shortest expression of the function.

boxArea : Float -> Float -> Float
boxArea width height depth = area * depth
   where area = width * height

I know that the let .. in syntax would give more imperative look so new coders who started with JavaScript can easily to join the getting started tutorial. But, at some point on the learning path when the word functional takes it right place in the user’s mindset then imperative style may not be really suitable.

This feature may not be so important in expressing logic into code but I think that it would give some specific tastes of the code somehow.

[kanishka]

I am willing to attempt to launch the industrial user group. The company that I currently work for has about >35 full stack devs of various levels using elm on front end. My initial agenda would be to set up an opencollective with each interested company contributing $1 per active elm developer and simply voting on what topic areas they would want future industrial funding to be spent on. I’ll ask my employer in mid January. If Rupert or others want to help administer the open collective, I would be happy to split duties.

It would also be interesting to have the industrial users group use a membership model based on employees joining instead of just companies joining.

I personally have no religious devotion to elm. I assume my next job will use react because prior founders picked it. I have advocated for and taken radical steps in my career to use Haskell, scala, etc, but I am sort of retired from FP advocacy right now (happy to use it if someone else chose it though). I am using elm as a coincidence currently.

[Laurent]

@thinhtranhnvn

From my point of view, what Elm may really needs is to add up features like Type Class and declare it the version 1.0.

It has been discussed extensively, for instance here…

[lydell]

@thinhtranhnvn

From my point of view, what Elm may really needs is to add up features like Type Class and declare it the version 1.0.

From my point of view, Elm should declare version 1.0.0 now and not add any new features. It’s better to focus on:

• Fixing bugs in core packages.
• Fixing bugs in the compiler.
• Improving error messages for records. (And other sub-optimal errors.)
• Improve and finish documentation.
• Improve the packages “GitHub hash / user renames” situation.
• Maybe not be reliant on GitHub only for packages.
• Improve elm install, making elm-json obsolete.
• Incorporate successful experiments from elm-optimize-level-2.
• Provide binaries for ARM platforms.
• Improve the elm npm package.

Things that should be avoided:

• Syntax changes. Not even the “cannot pattern match on negative numbers” issue should be addressed.
• Type changes to core packages.

Then, longer term, maybe:

• Merge elm-format.
• Make improvements for tooling like the Elm Language Server, elm-watch, elm-review, Elm dev, Lamdera, elm-test. Maybe merge some of it.
• Syntax changes, if warranted. Like allowing any expression in record updates. It’s important to avoid such things in the beginning though, because then we avoid having to find the secret of knowing when to stop. And we don’t break any tooling. I think a key to the vibrant tooling community around Elm is the stable core language.

[rupert]

@lydell, I agree with the order in which you think things should be done. For the elm-janitor effort, I built a spreadsheet of patches and ordered them in exactly the same way - from the things that can be changed/fixed without breaking any existing stuff, down to changes that will introduce breaking changes.

My thinking is that conservative maintenance is the least controversial approach, and would allow the greatest number of Elm users to adopt the end product of this work effort. I remember for example, when discussing elm-janitor, that Jeroen was concerned about a fork of Elm forcing him to choose which way to continue with elm-review. Personally, I am very happy with Elm as a language and do not really want syntax changes, type classes, or whatever - at least in the short term.

Conservative maintenance also keeps open the possibility of re-basing bug fixes into an Elm 0.20 for as long as possible - given the history of the language so far, I trust that if Evan does make a new version, it will be good and something that I would at least want to consider adopting.

Of course, after enough time has gone by without this, and if a group of people can form and succeed around creating and managing our own maintenance version of Elm, that could be a solid foundation for taking the fork in a new direction. I think its too early for that, we do not yet know who will be involved and got to know and trust each other and form a group that are able to share enough of a common vision. But right now, there is a steadily growing case for organisations using Elm to get interested in its maintainance, because they are becoming dependant on it; their self-interest aligns with this aim.

Here is my spreadsheet of bug fixes, classified according to these categories, from least disruptive to most:

Pure Fix (Optimisation or Tail Recursion or Docs)
Runtime Exception
Change to API or Runtime Behaviour
API Addition (Backwards Compatible)
API Change (Breaking)
Change to Language Semantics

Elm Bug Fixes

[rupert]

@kanishka

My initial agenda would be to set up an opencollective with each interested company contributing $1 per active elm developer and simply voting on what topic areas they would want future industrial funding to be spent on.

The business I work for has around 5 Elm developers, although not all do it as their main activity. If you want $5 for starting such a thing, I will hapily contribute it. If you canvas interested companies, it would be interesting even to learn who would respond to this.

[kanishka]

I started this effort. Open collective is reviewing whether I can use the open source plan or if I have to create a paid project.

Who is interested in becoming an admin on this project at open collective? I don’t want to be the sole admin because I suspect my next job will force react on me, but I should be around for at least six months to a year.

[supermario]

Hey @kanishka – appreciate your enthusiasm!

Are you aware of the existing Elm Tooling - Open Collective? Perhaps consolidating there might be a better path.

However it’s also not totally clear to me what the purpose is for this funds gathering? You said “topic areas they would want future industrial funding to be spent on” but I’m not sure what this means.

[kanishka]

That collective makes sense for a subset of projects that may emerge, so if commercial users prioritize tooling contributions, the campaign can happen through that open collective.

---

I am still forming my thoughts, but here are some initial notes:

• Focus on commercial users and evangelists (as opposed to hobbyists, academic users, and individual open source application developers…a team of open source developers working on one open source elm application may end up aligning with commercial users needs as well)

• Start by focusing on building up a list of commercial users and building consensus (via surveys/polls) on most pressing needs

• Keep needs open ended (e.g. compiler maintenance, library maintenance, tooling, documentation, marketing)

• If there is sizable interest and clear pressing needs, then launch fundraising campaigns aimed at corporate donations of either engineering time or cash

• Try to integrate with existing efforts like elm-companies list and elm survey

[rupert]

It might be helpful to build some kind of economic model of Elm. I attempted to do this a bit when talking about elm-janitor, and here is a drawing from slides I made for that:

The idea is to ask, how much would it cost to develop the elm compiler? If Elm did not exist, and you as a business decided to create it and to fund the effort to do so, you would find a smart computer scientist type or small team of such and pay them to build it. $200K/year for 5 years does not seem unreasonable to employ such a person in the USA at todays money.

Then, making some hand-wavy estimated around LOC and $/LOC, how much to create all those packages that have been contributed? No idea, but valuing that around 10X the cost of the compiler and core, would not seem unreasonable.

What valuations can we put on commercial users around that? Elm at a Billion Dollar Company with Aaron White

As a business the compiler, core libs and package system and 3rd party tools, are value you get for free, but of course it comes at a cost too. So total cost of ownership is what really needs to be considered. Is the value/cost better for Elm versus React say? Our assumption is that businesses do see a good ratio here.

What about risks, the potential costs associated with a business creating a dependency on Elm? The way to think about this is $/LOC of Elm code being re-written into say React. If a business develops a 10K LOC Elm codebase, what size of risk are they carrying. Contributing to open source can be compared with cost of insuring it as a risk.

And so on.

[supermario]

Sorry I’m still really confused, maybe I’m missing something obvious.

If there is sizable interest and clear pressing needs, then launch fundraising companies aimed at corporate donations of either engineering time or cash

What I don’t understand is what happens after this step. Where is this time and money directed at? Say to make it super clear: commercial group decides “we need more marketing!” or “we need type classes!” or “we need kernel code available in every package!”. So we gather up $2000. What happens then?

Edit: to be super clear cause tone is lost online – I’m not trying to critisize, I genuinely want to understand what you imagine will happen. I’m also trying to avoid making a bunch of assumptions.

[Carsten_Konig]

Exactly - what could people expect for their money? What are the goals and how open to public/investor discussion is this going to be?

I’d recommend my company to invest some money but I nobody is buying thin air sorry.

[kanishka]

I think reaching even consensus on priorities will take six months to a year, let alone starting a fundraising campaign after such consensus is reached.

Thinking out loud, I would start out by selecting the most trusted, established active contributors to be the delivery leads on any given campaign and fundraise on the delivery leads’ reputation and plan for development. I see the purpose of opencollective as providing transparency on delivery progress and where funds are spent.

For example, if marketing ends up on top and people choose a new website as the way to improve marketing, then we would choose someone who contributed to elm-lang.org or someone who has worked on an elm book and ask them to lead the effort, and have them delegate blocks of development time to individual contributors and pay them through opencollective. I am not saying that a website or marketing should be the top priority, just giving an example.

[rupert]

I think more than money, what is needed is people to contribute some of their time towards the effort to maintain Elm. There is a problem though, and that is that people cannot do this, because only the BDFL can make changes to compiler+core. People have contributed time to document issues and make PRs, but are blocked from completing the loop and seeing those efforts merged into the work and made available to all. My feeling is that this has had a negative feedback on the community, and people are increasingly less likely to contribute PRs as a result.

So this presents an obvious first step that must be untertaken - creating some infrastructure to distribute compiler+core packages independently of the existing infrastructure. Its helpful in some ways to have this obvious blocker to progress, because it makes a neatly bounded first project for any community driven open source effort to focus on.

The attempted infrastucture (GitHub - eco-pack/eco-server: Alternate Elm package server) I created to support this is not currently used but is still running on AWS, and costing me less than $5/month. Hard to know what it would cost if it were used in place of package.elm-lang.org as I don’t have usage stats for that, but I would guess somewhere in the 100s to 1000s $/year.

My proposal is therefore a funding target of approx $500, and finding 1 to 3 people/businesses willing to contribute the time and effort to create an independant infrastructure to distribute a fork of Elm compiler+core packages - the only change being that the forked compiler would pull its packages from the alternative package site. This is an easy to understand project, as non-controversial as it can be, with minimal change set to the tools.

[rupert]

@kanishka Was asking me about my economic model, which I didn’t do a very good job of explaining. As I like to keep the conversation in the open, here is my reply.

Yes, this is not money that needs to be raised.

I probably did not do a very good job of explaining my economic model - the point of it is is really just to act as a frame of reference when the conversation turns to money. Essentially I am claiming that Elm as it stands is worth something like $11 million.

Maybe the company you work for has a warehouse with $11 million worth of goods in it. You can bet the finance department knows this and also the fire, flood or theft risks. The warehouse will be insured to cover a potential $11 million loss if something goes badly wrong.

Imagine that since Elm is not maintained satisfactorily, a concensus forms that businesses should not use it. The company you work for uses Elm extensively, but needs to ask the question - If Elms falls out of favor and we are the last company left using it, we have to choose to maintain that £11 million software stack ourselves, or more likely abandon it and move to React/Svelte/Vue/Typescript/whatever. I cannot guess the cost of doing that, as it depends on the codebase to be re-written, but for example I work on a 150K LOC Elm codebase, which would easily cost > $1 million to rewrite.

The alternative is that we get people on board from a wide range of organisations using Elm and share the maintenance cost of that $11 million software stack between them.

Some places may be happy to chip in a $ contribution towards the effort. Some places are going to want something in return. Ultimately control is what gives them security.

Currently if you hit a bug in Elm, you have no way of getting it fixed. If Elm was a “real open source” project that had multiple maintainers and actively reviewed and applied acceptable submitted patches, and had a public mailing list where the review process is conducted in an orderly and fair way, there would at least be a process for fixing things and a degree of control.

A business with a serious investment in Elm might also want a degree of control by having one of its own staff become one of those maintainers.

So the $ contributions, patches or funding maintainers are all economic costs that we might ask to be contributed towards a shared effort. Of course staff time can be translated to $, so all of this can be though of as the baseline cost of insuring that $11 million software stack.

My gut feeling is that the maintenance cost is much lower than $200K/year. $200K/year would get you 1 full time employee of the educational level of Evan - a computer science graduate with the ability to drive the language forward. Maybe thats something that we ultimately want to do, but I think the baseline cost of maintenance would be far lower. We are really just talking about reviewing and applying patches.

I think the patching type activity is better contributed towards by allowing company staff a bit of company time to be maintainers of Elm. It would be better if more people are involved in this activity, rather than finding money to fund 1 person. The reason I think that is that patches would need to be carefully reviewed and assessed for their impact on the overall system - we want to fix bugs not introduce new unforeseen problems, and this needs to be conducted in an open and transparent way where it can be seen by many eyes in order to avoid mistakes.

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

Just occurred to me that I should add the caveat. When I say “Elm” I don’t mean Elm as it currently stands, or that this is the right model for Elm, or that I am giving advice that things ought to work this way. I am talking about a model for a hypothetical fork of Elm that might better suit the needs of commercial users.