Elm has been out a long time and that is a really short list. Are there key reasons elm hasn’t seen more adoption? (Please don’t bother with comments about corporate drones etc.... companies are pretty good at taking advantage of a good thing)
I ... don't think that's true?
There are lots of "superior" technologies that just haven't won. e.g. the handful of people who use it _swear_ by Datomic. And there are load of so-called "inferior" technologies that are still widely relevant. Mysql? Php? Wordpress? They pay a lot of software developers' bills.
I work at NoRedInk, and we pay Evan Czaplicki to work on elm. When we started to migrate to Elm, our eng team was under 10 people. Larger companies, e.g. even NoRedInk today, tend to be less agile.
- yearly updates in the official blog - it's very hard to convince a team when it smells like abandonware - besides not being. The fact that the language has a single centralist owner does not help (just look at the blog posts, it's always "I did this, and that", not "we".
- active work from the owner to shut down another PKG manager (Pine, if I recall correctly), because it allowed usage of """kernel""" modules
Yes, but a minor point I'd like to make is that because of how Elm is organized, you just put stuff in your src folder and it immediately compiles (since there's no JS FFI etc.). So it's not as big of a pain as it might seem.
1. Development of compiler and core libraries strictly BDFL driven (at least used to be)
2. Fixing some important compiler/library bugs takes years
3. No way to host private package repositories
I still use Elm personally, although these are very valid concerns.
4. The language is still unstable. Porting our code to the next release could be a huge task.
5. Elm + JavaScript is generally painful.
6. Few libraries, some of them unmaintained. Combined with the near-impossibility to use JS libraries from Elm, it would increase our work too much.
I would never use such a thing in production.
Getting rid of kernel modules for everything others than core packages in 0.19 made JS <-> Elm interop even more painful and broke some apps. I forked the compiler [1] to support that, although it is not upto date (still stuck at 0.19.0)
That's kind of related to the dictatorial community management. Relatedly, you still can't write a generic sort function.
On the other hand, I have been using Elm for solid 4 years, and there are so many moments of Pure Joy of working with Elm, that JS/TS is unbearable.
I have dropped many offers to work on React TS codebases, because that kind of language is such a downgrade after Elm ... IMHO
This is not my experience at all.
I'd use PureScript next, or maybe ReasonML.
Elm is stagnant and its dictator seems to be quite insistent on keeping it that way.
But was it a well-known list before this? I hadn't seen it, and know of a few projects that could have been on there.
What I'd like the list to include, though, is some references to the companies discussing using Elm. Pros and cons, the scale to which it is used etc. For instance for Vy there is this blog post: https://blogg.bekk.no/using-elm-at-vy-e028b11179eb
On that note, it's interesting that publishers have already put out print books.
'If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.'
To a significant part of the community 1.0 means a stable API with considerations of backwards compatibility.
I know many people aren't using pure semver but the implications of a 1.0 have in my opinion extended beyond that point and beyond semver in general.