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.
And there really aren't any ways to make generic functions.
I really do like the paradigm of unidirectional data binding to the UI and the message system, but Elm The Language itself is basically the Go of functional programming; when you point this out on the subreddit or to a fan, you'll get banned (I have) or condescend to in the most obnoxious way, with plenty of the word "folks" peppered in.
This part seems to come out of nowhere? Your parent disagrees with certain design choices, but they didn't say why they disagree, and it seems unlikely to me that they disagree because they want elm to go mainstream.
Unless you think that making different choices would turn elm into something mainstream? If so, I'd be interested to hear justification for that.
> Unless you think that making different choices would turn elm into something mainstream? If so, I'd be interested to hear justification for that.
I don't think it would. It would end up being just another coffeescript without any notability. It is precisely so interesting because Evan is being pragmatic. No matter where it ends up, until now at least it is far more valuable and interesting than just another kitchensink.
Fair enough. That hasn't been my experience, but it's not important.
> It would end up being just another coffeescript without any notability.
Ah, perhaps I was unclear. By "turn elm into something mainstream", I meant something like "make it indistinguishable from other mainstream things with nothing to distinguish it". That sounds like what you mean here.
In any case, I don't think this is true, and I'd still be interested in hearing your reasons for thinking it.
(For example, are there specific design decisions that you think (a) people are clamoring for Evan to make differently and (b) would turn Elm into something that isn't distinguished from anything else? I can't think of any. Parent seemed to be referencing kernel code, but Elm 0.18 had that, and it wasn't just another coffeescript.)
> It is precisely so interesting because Evan is being pragmatic.
What do you mean by "pragmatic", here? My natural interpretation would be "Evan is making compromises to the core design to make Elm easier to use", but that doesn't seem to fit. If that's what you mean I just plain disagree, and I think Evan would too. (Though, again, if that is what you mean then I'd be interested to hear your reasons for thinking it.)