I love Elm. Could the elm-lang.org website be updated in any way, and/or can any release be made, even if the difference between 0.19.1 and 0.19.2 is that it adds the words “It is 2023, and Elm is still alive”?
I promote Elm to companies, saying they should adopt it. The hardest problem is that when people look at news and see that the last release was 3 YEARS AGO (emphasis is theirs), they tell me that they cannot invest in a possibly dead language. I then explain that it is still better than any other front-end language out there and it is still worth it. And then they say the language is dead and they cannot embrace it.
Given the de facto maturity of Elm at this point, I wonder whether there might be some positive effects in declaring it to be at version 1.0? Of course, that isn’t necessarily as simple as it sounds, since it would attract a lot of attention which people would need to be ready for.
I think it has to start with delegation. Elm has built some community informally with interesting libraries, but elm leader(s) haven’t formed a formal industrial group, gathered funding, and directed it towards marketing and continuous contributions to the compiler. The industrial users will probably keep getting by with the current state, but there is a huge opportunity lost in adoption by less proactive developers and managers. There is no technical reason why people choose react+typescript. I think it’s essentially lack of marketing budget for elm.
In terms of organic activity, one can observe:
volume of messages on elm slack, incremental-elm discord, and on this forum
web content highighted on elm weekly
job listing activity on elm slack
some quality essential packages and tools with steady releases
In terms of improving marketing right now:
I would submit PRs to elm-companies to get it up to date
post more questions here and in elm slack to keep generating useful content for future beginners (and if you work at a company that uses elm, use public channels to discuss and teach elm between coworkers instead of discussing in company slack channels)
post short tutorials to dev.to + link to more example repositories on GitHub/gitlab/codeberg
get involved with GitHub issue discussion on essential elm packages
As someone who spent a little time working on a language website, I don’t know if they serve any real purpose any more, now that discourse and slack exist. At best, they serve as Wikipedia page to define the essential goals of the language and then direct you to other content for fresher data. If someone asked me to adopt java or javsacript for a new project, I wouldn’t go to the Java or JavaScript homepages (and I doubt many Java or Javascript developers even know about such a homepage or bother to visit it), I would go to the homepages of the key ecosystem packages and possibly post a question about what is the best package for x and how well is it maintained on a discussion forum.
I also think that is what needs to happen. But we also cannot expect it to happen either by asking for it here, hoping Evan will do it, or begging for our PRs to be merged. The only practical route to this would seem to be to fork and create something new with those aims.
I have tried to move in this direction previously with elm-janitor · GitHub and eco-pack · GitHub and fully intend to keep going with these things. I just haven’t got the time to put into them right now.
(BTW there is an Elm Foundation, which Evan set up to own the rights to Elm and I think also to act as a funding vehicle, not sure exactly what for but I think he had some educational activities to fund - doesn’t seem to be the industry group we want though).
My impression is that Elm is done pretty well and it works well to build an ecosystem around it, so most of the innovation right now is happing in the tooling which is amazing and keeps getting better.
It appears Elm is still actively maintained and perhaps a new release will be coming:
There appears to be an informal core team, which is good.
It may get uncomfortable at times when we don’t see more features being added. There are multiple ways to look at this. One quote that comes to mind:
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. – Antoine de Saint-Exupery
Many have raised this concern and if the past is any indication, things may not change. However, what we have now is working well for most of us. What you can do is promote elm by sharing success stories, blog posts, develop tooling/packages, etc. This will probably do more to keep Elm alive than anything.
The tooling has/is going to hit a wall where they will need to modify the compiler to make further progress on hot reload, continue improving on editor integration. The compiler itself already has known issues with space leaks, with commercial users advising each other to run with GHC rts -s option defensively to detect when space leaks are occurring. There is also basic maintenance keeping up with GHC releases and changes to Haskell. People will get by, but these issues will start to add up. I hope one of the efforts to fork stick, so that elm can remain the classic language with low maintenance expectations and something else can become the actively maintained language aimed at supporting increasingly larger commercial teams and codebases.
Just to clarify: That’s a potential new release of the npm package, not of Elm the language/compiler. It was done by a one time collaboration, not an informal core team. I don’t feel part of an informal core team at least.
A nice place to understand the current status of the Elm compiler is:
And an AWESOME talk to understand some of the principals behind Elm is:
Your suggestion to just release a “dummy” update goes against a lot of the things Evan talks about in this talk. So don’t expect this to happen.
And I see no reason to rush a new update. We know Evan is experimenting with different approaches (and also recently being a father). At the same time, some amazing people are working on projects like elm-land, elm-pages, elm-review, and many others. Maybe you could point your colleagues to these projects. Maybe changing the approach from “let’s adopt Elm” to “Let’s adopt elm-land|elm-pages”. Once they see those projects are in active development they may present fewer restrictions.
And I really don’t like the idea of forking Elm. There are alternatives if you must. And elm’s idiosyncrasies are what created such an amazing and unique technology.
That being said, I do have some complaints about some things not being updated. Just some small things, like the home of elm-lang. org. Evan uses a really interesting way to update things, by batching work. That helps a lot in some aspects but may leave some things in a weird situation. Like the comparison with Angular 1 and 2. Nowadays that’s mostly totally irrelevant information. Would be better if it was a link to another repo, which someone else could keep up to date. Or, it’s not feasible to keep up to date, just don’t give this comparison at all.
And the News page being very out of date is something that I think could be easily fixed. A new simple post, something similar to the text I linked in the first URL, would be sufficient to demonstrate that the project is not abandoned.
Anyhow, I’m really pleased with Elm and wish there were more projects like it in other areas.
I don’t particularly like the idea of a fork either. There does not seem to be an alternative to get some maintenance work done on the compiler and core libraries though, and I think without that people are right to be a little suspicious that Elm is “not maintained”. If business are going to invest $millions building a new software product, they do need a way to get patches picked up and incorporated into the system, as and when they run into problems. Luckily the overall quality of Elm is very high, so there have not been too many problems, and certainly very few real showstopper ones.
A maintenance fork is what I am doing with elm-janitor, and you should think of it a bit differently to a full fork. The idea is not to lead Elm in terms of features and try and set a new direction for it, but just to patch stuff and make sure all patches are documented and made available for the upstream project (Elm) to pick up if it chooses to. In that sense, its a bit like the relationship a Linux distribution has to the core kernel.
In the thread where I ask if others have run into GitHub action OOM, you can see another commercial user noting they have hit OOM issues, pointed out one of them specifically. We have one OOM issue in our GitHub action builds also, recently mitigated by using different garbage collection algorithm, but still occurs sometimes. I haven’t had time to reduce to a smaller reproducing example, from the 1300 modules of the app, but will create a bug report when I do get time. It sounds like other commercial users either have small codebases or aren’t complainly loudly.
Generally, I am worried that no one is proactively applying this to the compiler implementation - GitHub - ndmitchell/spaceleak: Notes on space leaks - and if no one is, I don’t know if using Haskell (instead of rust, ocaml, etc) makes sense, because it feels like you are setting yourself up for a program full of space leaks. Maybe Evan or another early contributor already is a master of avoiding space leaks or has diagnosed them already, and I am worrying for no reason…
I checked the elm/compiler issues, and searched for things like “OOM” “github actions” and so on, but I did not find the issue. Perhaps I missed it?
The first thing you should be doing if you are concerned about this, is to create a well documented issue against the compiler that explains what the problem is and how to reproduce it. I recommend you do this for this issue.
I don’t think that an empty news section is really the point here. It is an horrible first impression, but inspecting further the Elm ecosystem and community won’t give different results. Stale issues and lacking packages are just around the corner, bumping to a placeholder version just to say “Hey, I’m alive!” won’t convince anyone.
It is safe to say that Elm is, right now, exactly where it wants to be. Hell, the roadmap that has been linked says “If you like what you see now, that’s pretty much what Elm is going to be for a while”. What’s “a while”? Well, the document itself was last updated two years ago.
I see no proof of long (or short) term objectives other than vague “exploratory work”, and I’m not really persuaded that third party tool work counts as active maintenance - at least, not the one I’m witnessing on Elm.
There are a few examples of companies successfully using Elm for their goals. It is also very reasonable for any developer team to be wary of a language with such a peculiar history and life cycle. Perhaps if you wish to convince more people to work with it you would be better off looking at similar projects, like Gren. It’s still in its infancy but promises to be a more up-to-date version of Elm.
Still in alpha, as yet unproven, and following the same BDFL model. I won’t say it will neved get to a better place than Elm, but this cannot be a serious recomendation?
With Elm you have a great tool and well proven, and known to have very few issues. What is wrong is the way it operates and presents itself to the commercial world. So I would say a more logical step would be to take Elm and fork it to fix those things, rather than starting again from scratch.
Gren seems to have taken the request not to use the name “Elm” for forks very seriously, but I believe it is Elm with some bug fixes and some features removed.
Quoting from the first release announcement: “While we could spend considerable time and effort in creating a language which would look very similar to Elm, we’ve instead decided to fork the compiler and core packages, and use that as the basis of Gren.”
The only real downside compared to Elm right now is the lack of community - which is by no means a minor problem. Of course most company rejecting Elm would refuse Gren as well, by virtue of being in an alpha state.
I never complained about the BDFL model per se and I’m not advocating for the general adoption of Gren against Elm. My point was that - in the long term - moving to a different/forked tool seems to be easier than trying to change Elm, especially if the requirement is more frequent updates or a bigger focus on PR.
Yes, I have watched most of Evan’s talks and I remember this one in particular, but I didn’t feel confused about the topics discussed here in the first place.
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.
The BDFL model is at the heart of Elms problems. We cannot change Elm, and are not entirely satisfied with our BDFLs rate of change or application of effort on maintenance work and refusal to delegate this work to others. I would have been more excited about Gren if Robin had proposed setting up a more inclusive open source model to develop it. That may yet happen of course, but its beyond our control so we cannot rely on it.
It is entirely possible to create a fully compatible fork of Elm (just give it a different name!). The main obstacle to be overcome is to develop an alternative package site to distribute it.
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.
I’m not very optimistic about a fork that changes nothing but the name and fixes a handful of issues. I feel like it wouldn’t be worth it to further split such an already small community. Honestly, it sounds depressing.
