
Do we need to move away from Elm? - sridca
https://www.reddit.com/r/elm/comments/81bo14/do_we_need_to_move_away_from_elm/
======
shaki-dora
Elm's management has left me with the impression of a really smart, well-
intentioned hellscape.

Searching for almost any problem I encountered, I'd invariably find two or
three Github issues that were exact matches. These were, with impressive
consistency, closed about two hours later with a link to some "Meta-Issue for
Improvements to our Float handling" or something like it.

That issue, in turn, would usually be closed by some check-in that had nothing
to do with my original problem.

Other times, the link to the "Meta-Issue" would get you a 404 because the
compiler repository was merged with the documentation repository, and both
were subsequently moved to the Elm-Lang project, then renamed to "elmlang".
Oh, and feature requests are now part of project elm-future....

Elm is seriously nice to use. But it'd be twice as good if they lost all
accounts that have admin privileges for the Github tickets.

~~~
RubenSandwich
A major problem that I see with Elm is that it seems, from the outside, to
have a bus factor of 1. Looking at the commits for the compiler and other core
libraries you only see one name over and over again: Evans.

Evan has created a very streamlined and pleasurable frontend experience, but
IMO his tight control of it will lead to it's demise for a variety of reasons:

1\. Something happens to Evan (Hopefully not)

2\. Evan decides the foundations need to be replaced (For example if he moves
away from the 'Elm Architecture', it will cause a great rewrite and when great
rewrites happen developers evaluate other options. e.g. Angular 1 -> Angular
2.)

3\. Evan gets burnt out

I'm okay with a BDFL, but not a sole maintainer. I think he needs to raise up
others to maintain it for it's long-term health.

Note: Creatively I can understand his desire to control the experience. It
also make it feel very unique as a programming language where you are guided
in a very narrow path in development, but I believe like most creative works
they get better with remixing. When the idea is allowed to be evolved, played
with, broken and pushed. Yes, most of those changes will be bad but how else
can we know besides trying? Those extensions of Elm's ideas are sadly
currently happening outside of the Elm ecosystem because of Evans control,
which I think will also lead to it's slow demise.

~~~
steinuil
I think Evan is too protective of the language to let anybody else maintain it
right now, the first step would be for him to realize that he should give it
up just a bit.

------
chasote
I'm on the side of why don't you just let Evan do his thing? Maybe a big part
of why Elm is kind of really awesome already is because it's being developed
differently. Just let a cool language develop differently this time! It might
turn out to be great.

And for people who supposedly have so many lines of an alpha language in
production, why are you confused about how Elm is being developed? I'm not
even using it, but just an interested follower, and it's been pretty clearly
explained how he plans on developing it. A couple highly visible threads here
and there (some in quite poor taste too) and you are bound to have been given
solid, well thoughout references to why Elm is developed this way. I've seen
tons of disclaimers that you are using an alpha language in production at
risk. No one was misled.

~~~
smoe
I'm all for letting people do their thing and try different approaches.

But honestly to me it seems the elm community wants to have their cake and eat
it too. Of course that is not a trait unique to them.

As somebody not involved with elm I mostly get to hear about the language from
the marketing side. And it does get advocated as production ready (or as least
as production ready as anthingthing else in the js world, to paraphrase some
talk) and the alpha status, it being still a young language and use in
production at own risk only ever seems to really come up when there is some
push back.

E.g. I can't see any mention of being "alpha" or warnings on the elm website,
besides the version number indicating it. Instead it says things like "elm
guarantees no run time exceptions in practice", but when I go to Github
issues, I find several of them, including intentional and accepted ones.

It seems to be a neat language, but for now I'll just stay away from it and
let them do their thing.

edit: grammar, wording.

------
tazjin
It's an interesting topic. We use Elm at work, but I don't work with frontend
development so I don't have a lot of hands-on experience with it.

From following a few of those Reddit thread (the linked one and also [1] about
a week ago) it seems like there is some growing concern about the BDFL-type
development model that Elm is using.

From a casual user's perspective and as someone with a background in Haskell
development, Elm appears sort of unmaintained (PRs being ignored, no new
releases/updates/anything in a long time) and unfinished (there are many
"Haskell-features" that Elm has no equivalent to (yet), which leads to
developers writing a _lot_ of repeating code especially in areas such as JSON
(de|en)coding).

None of our work Elm code bases are particularly large (yet), and the
developer doing the bulk of our frontend work is also a Haskell person by
heart. We'll be staking out PureScript as an alternative, though we'd probably
like to keep the idea of the "Elm architecture" alive there, too.

It seems as if the Elm team is currently doing what SPJ once referred to as
"avoid success at all costs" in order to ensure that they really nail the
features they care about, but they're doing it _after_ already having started
a hype- and marketing wave several years prior, which is leaving people
stranded in uncertain territory.

We'll see how it works out ...

[1]:
[https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing...](https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing_elms_momentum/)

------
crusso
I've been using Elm on and off for projects for the last couple of years. I
find that most of the complaints are just discomfort at how Elm isn't
developed the way that many other projects are. It gets in people's heads that
they have to trust in Evan's judgment when they don't see a new release
popping out every quarter.

I actually like the pace of releases and lack of frequent breaking changes.
I'll put some projects aside for 6 months here and there, then come back to
them when I have time. Most rapidly-evolving frameworks require you to update
all your libraries and fix a ton of breaking changes when you don't touch them
for a few months (I'm looking at you, Swift). After I spend all that
maintenance time, I often wonder at the value of those changes in the first
place. Were they really changes that buy me new flexibility with the language?
Or were things just renamed and shuffled around with syntax changes made for
no great reason?

When talking to people about using Elm, I discourage them from using it if
they're the kind to obsess over the release cycle of a framework that's stable
today and that allows them to get quality work done.

~~~
kungfooguru
You like having a fix open in a PR for 2 years and then learning that your
work around for the fact that fixes don't get merged or released is going to
be also blocked? Because that seems to be what is happening to the person who
opened this reddit thread.

~~~
rtfeldman
There are other workarounds; the poster chose that one but didn't have to.

------
rishav_sharan
I really want to love elm. But i dont want to use it for any major project
mainly due to its development model. I ca understand the next version taking
time. But having no transparency about whats going on and when will it drop
doesn't gives me confidence about the project. There are just too many issues
and untouched PRs in there.

~~~
dennisdamenace
I’ve been using Elm since 0.16. Development is slow and thoughtful. Perhaps
0.19 will be a disaster, but I doubt it.

In the meantime 0.18 has been a very productive language.

One thing to understand is Evan wants Elm to be a language and not bound to
JavaScript. This is the sound motivation behind blocking native packages.

~~~
archgoon
Rust is a language, and it can bind to C libraries. Java can import DLLs and
shared libraries. Haskell can do this too. All popular languages that can run
on a server can spawn a process and communicate via file descriptors.

Useful languages can interop with other languages.

~~~
always_good
Well, Elm does have interop with Javascript through ports. The mechanism is
asynchronous which creates an explicit crash boundary at the expense of a
mechanism that is more roundabout than just calling `foo x` when you want to
wrap a Javascript library's `lib.foo(x)`.

Elm 0.18 and below (not sure what 0.19 is doing, it's not released) has
synchronous interop through native modules, but those have been discouraged
and documented as "do not use, will change in the future" since the beginning.
And you can't easily publish them to the package repository.

To say Elm doesn't interop with Javascript is just wrong.

You may disagree with Elm's stance on its synchronous interop, but you're just
disagreeing with trade-offs. Like all trade-offs, just because someone chose
different ones than you doesn't mean they were oblivious to them.

~~~
archgoon
I'm actually in full agreement that there are many ways to accomplish interop,
with a variety of tradeoffs. It is precisely for that reason that I disagree
that the statement

'One thing to understand is Evan wants Elm to be a language and not bound to
JavaScript.'

is a good explanation (or a 'sound motivation') for the current design
decision. Thank you for expanding on the goals of the current design. People
less familiar with Elm, such as myself, have learned something about Elm's
capabilities and strategies for dealing with interop.

------
skybrian
It seems like this is the sort of thing that causes projects to fork. For
example, egcs from gcc and IO.is versus node.js. In those cases it apparently
worked out well (from an outsider's point of view), but I'm sure everyone
would prefer to avoid the drama.

------
msangi
I think that the main problem with Elm is that Evan wants to design the
perfect system.

This is of course a laudable goal but I think that clashes with the complexity
of the real world.

A consequence of this is that if you want to do something Evan spent time
designing a solution for you're going to have an awesome experience, he is a
great designer, but on the other hand as soon as you try to do something
different you're out of luck.

This has the nice effect that what's there is really nice but there is no
middle ground and you either get something that is well deisigned and
extremely polished or nothing at all.

~~~
always_good
I liken it more to Evan investing "hammock time"
([https://www.youtube.com/watch?v=f84n5oFoZBc](https://www.youtube.com/watch?v=f84n5oFoZBc))
into Elm because he has loftier goals than just another SPA abstraction. Which
is a bit different than perfection.

There are just too many cats that can be released from the bag that would be
too hard to reverse once out in the ecosystem. Classic example would be
allowing native modules into [http://package.elm-
lang.org/](http://package.elm-lang.org/).

This puts you in a position of treading cautiously with the long-term in mind
while your users may clamor for quick fixes that jeopardize the overall
strategy.

So I agree with you. This results in the "something good vs nothing at all"
release cycle that you point out, but I think its a more accurate explanation
of why that is.

The rest of the issues seem to be related to his limited bandwidth. And I
suspect Elm is tied so much to his bandwidth because such fundamental design
is still being decided.

------
olingern
Like others have mentioned, it seems that elm has done a great job of
promoting itself, but lacks the structure to make big changes.

It screams of needing some sort of governance and RFC process ( edit: seems
that there is an RFC process [1]) so that all parties could make their case.

The Angular 1 -> 2 transition should be a lesson to most that if you leave
your users hanging, they'll go find another ecosystem.

[1] - [https://groups.google.com/forum/#!forum/elm-
dev](https://groups.google.com/forum/#!forum/elm-dev)

~~~
sotojuan
If I recall correctly, Elm grew out of Mr Czaplicki's PhD thesis or project.
It seems that he still considers it _his_ project, which is fine for him and
his employer but it does it make it hard for those not close to him to see
where the language is going and get support.

In a perfect world (according to me), Elm would have 5-10 people in its core
team, with at least a few of those tasked with triaging issues and PRs. That
wouldn't mean "giving up" control of the language and its future.

~~~
olingern
> Elm would have 5-10 people in its core team, with at least a few of those
> tasked with triaging issues and PRs

That would be amazing, but I see this being very similar to Node in its
infancy. It took a fork (io.js), and a lot of strong opinions to get Joyent to
relinquish its grip on the ecosystem.

I think what the developers who forked Node into io.js showed was competency
and care with regards to progress. I'm not sure that could ever happen in the
elm ecosystem due to it being somewhat small and niche.

~~~
always_good
If Node was in its infancy when the io.js fork happened, then Elm is downright
fetal. I don't think you can compare them.

It seems to me that the extreme BDFL governance of Elm is also its strong
point at the expense of being then limited to that bandwidth, it's weak point.

Unfortunately, delegating work does not come for free and a great deal of
energy will be burned in people management. Unless you're clairvoyant, it
can't be said whether that would be any better for Elm or mire it in an even
thicker mud.

Elm has a lot of unknowns that someone has to sit down and make decisions
about because it wants to generalize over environments beyond browser-side
Javascript. I think that sits at the root of why you can't just delegate out
core contributor access.

But trying to do that generalization in the first place is also why Elm has
some really interesting potential in the long run than just another SPA
abstraction.

------
pmarreck
Is there a licensing reason why someone couldn't just fork Elm and come out
with a new less-dictatorial leadership-driven project?

[https://github.com/elm-lang/elm-
compiler/blob/master/LICENSE](https://github.com/elm-lang/elm-
compiler/blob/master/LICENSE)

Actually, what IS that license? Is it completely unique and not one of the
more standard ones?

~~~
nemothekid
The License looks like a modified MIT, with 2 extra clauses (the binary must
produce the copyright, and the author's name can't be used to promote anything
else).

Reading through the thread, others don't want to fork because it would split
the community of an early language. They don't want to take Elm in a different
direction, just bugfixes.

~~~
electroly
It's the three-clause BSD license with the words "the copyright holder"
replaced with the author's name.

------
danharaj
There's a fairly direct migration path from Elm to Haskell + reflex, though
it's much less user friendly. You'll have no technical limitations tho.

~~~
thepratt
There's PureScript to add to the list as well.

------
rtfeldman
As I've participated in Elm's growth over the years, more and more I feel for
the React devs who are pulled in many different directions by impassioned
voices on every side. People have really strong feelings about how open source
software authors should spend their time.

I read the GitHub issues linked in the OP of that thread. Two are feature
requests, and one is a bugfix for a behind-the-scenes problem which apparently
has no noticeable symptoms. I understand OP's frustration that these haven't
been merged or closed; nobody _wants_ to do workarounds, and everybody wants
feedback when they post on GitHub. I'm also personally sympathetic to the idea
that Elm core libraries should have more frequent minor releases, which I
agree with.

The thing is, I also understand that when open source authors prioritize
engaging on GitHub, that implicitly means not prioritizing other things.
People think "how hard can it be to write one sentence of feedback as to
whether this will get merged?" but that's not how GitHub works socially.

An under-appreciated reality of OSS is that maintainers have two options:
engage in a back-and-forth with issue posters until the issue is resolved to
the poster's satisfaction, or brace for complaints that you're unresponsive.
If authors conclude other priorities are higher than seeing that issue through
to its eventual conclusion - however much time that may take up - it's
understandable why they wouldn't even begin that conversation in the first
place.

(Naturally, those who prioritize responding on GitHub are subject to
complaints that ambitious long-term projects are taking _forever_ and perhaps
deserve to be labeled vaporware.)

If you have a BDFL, some will say things are moving too slowly because the
BDFL doesn't have enough bandwidth. If you have a committee instead, some will
say things are moving too slowly because there's too much bureaucracy. Trade
flexibility for guarantees? Some will call that stifling. Trade guarantees for
flexibility? Some will call that dangerous.

We programmers have every possible combination of preferences, and those whose
preferences already align with a given project tend not to bother posting
about it online - because they're off happily using the thing that's worked
well for them. I think this is why I've found contributing to open source
consistently rewarding but frequently exhausting.

For reference, here's what Evan said about the big picture topic here:
[https://www.reddit.com/r/elm/comments/73ubxo/an_explanation_...](https://www.reddit.com/r/elm/comments/73ubxo/an_explanation_of_elms_policy_on_native_code/)

~~~
tazjin
Some loose thoughts:

A lot of this boils down to figuring out a delegation model that works for
Elm.

Does the BDFL of the language really also need to be the only person
maintaining core libraries? The only person maintaining project
communications?

In this particular case it feels like the Elm team is afraid of "losing
control" over the language.

That's often in direct contradiction with the project becoming more popular,
so for a while maintainers need to choose between advocating the thing they're
building and advancing it in the way Elm is currently being advanced.

Once things like [1] start appearing in the codebase you're basically asking
people to fork your project and what happens after that is unknowable ...

[1]: [https://github.com/elm-lang/elm-
compiler/blob/d07679322ef5d7...](https://github.com/elm-lang/elm-
compiler/blob/d07679322ef5d71de1bd2b987ddc660a85599b87/compiler/src/Elm/Package.hs#L72)

~~~
always_good
I've been using Elm for years now and it's always been openly admitted that
core abstractions are still being decided. You can just look at the change log
between versions (which are all sub-1.0) to see that.

You have to be okay with that to use it in production. Else you would have
used something more stable instead of decided to gamble.

I think Elm is still too early to bike-shed over governance model. And people
seem to think Elm is a lot farther along than it really is. Else they wouldn't
have the expectations that they do. Or they wouldn't go "I don't have these
issues with React."

I think the social issues Elm has are just what it's going to take if Elm
wants to arrive at something more compelling that just another language. If
there's a continuum with BDFL on one side and design-by-committee on the
other, then you're going to have issues no matter where you move the needle.

The upside of the bus-factor-of-1 approach is that you have a visionary in the
Hickey hammock. And the unavoidable downside is that you have to deal with the
bandwidth of one person which describes a lot of the social issues.

I think that anyone who is uncool with that reality chose the wrong language.
And a lot of the criticism that results from that, like this:
[https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing...](https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing_elms_momentum/),
starts to reek of the hot air of entitlement, to use Rich Hickey's words.

------
boubiyeah
Elm was a nice experiment, but people need to put things in production and be
confident they can fully maintain all of their code and dependencies.

------
Athas
I have been looking at Elm as an example of how to engineer the ergonomics of
a functional language, and how far one can come with a focus on simplicity and
consistency. Unfortunately, it also looks like it is becoming an example of
the problems of going too far. I don't actually mind Elm's weaknesses as
discussed in the Elm Is Wrong essay[0] - these look like an ordinary technical
trade-off - but the social consequences of how Elm is managed seem a little
more subtle. [0]: [http://reasonablypolymorphic.com/blog/elm-is-
wrong](http://reasonablypolymorphic.com/blog/elm-is-wrong)

------
augbog
Dumb question but I recently was looking at Elm and ReasonML (by Facebook) and
don't really know the difference... they seem to try to achieve the same thing
no?

~~~
mjaniczek
(Disclaimer: I only have experience with Elm, not ReasonML)

Their goals might align quite a lot (functional programming for the browser;
compiling to JS), but Elm seems to me more "pure" than ReasonML, and places
extra emphasis on correctness ("no runtime errors").

For example, ReasonML allows you to put JS code inside its source [1]. Which
might be great if you want that escape hatch, but might mean that runtime
errors are common when working with ReasonML. Elm trades a bit of convenience
for the enforced reliability.

[1]:
[https://reasonml.github.io/docs/en/interop.html](https://reasonml.github.io/docs/en/interop.html)

~~~
StreamBright
Yep, this is exactly why we use ReasonML instead of Elm. I want to be able to
write inpure code when I need it.

------
rs86
I don't get why not making it an option not to install "unsafe" modules

------
Bitcoin_McPonzi
I love Elm. We use it in production, though we're not primarily a "web"
company and it's used for admin UIs and simple SPAs.

Nothing in Javascript / HTML is very stable--I've hitched my wagon to so many
stars that burned out. Everything from XSLT to JQuery to Bootstrap. So the
fact that probably, something will replace Elm doesn't bother me.

It works now, it's stable, and it hides most of the crap from me so I can just
code. It helps that I've been a "Functional Programmer" since 1980 when I
first learned LISP, and that our core products are done in Erlang and F#.

------
mrbill
I hate duplicate-named projects. Thought for a moment this was about someone
discussing upgrading their text-based mail client.

------
stesch
I tried Pine for a few months but ultimately changed to mutt. But today I'm
using Thunderbird.

------
cperciva
The most recent release of elm was over a decade ago. If there's anyone left
still using it, I'd definitely recommend switching to mutt.

~~~
always_good
People make this joke every single time Elm comes up.

Even if you somehow meant it in earnest, which wouldn't make sense here, it
exposes you as someone who couldn't even be bothered to click the OP link.

~~~
acheron
Alternately, it exposes the creator of Elm as someone who should have thought
harder about naming, and not chosen the name of a very well known piece of
software that predates theirs by a few decades.

~~~
pmarreck
> that predates theirs by a few decades

Have you seen Evan? He's like 12. (Sarcasm because I'm 45 and now everyone
around his age looks like 12.)

