
State of Elm 2017 Results - myth_drannon
https://www.brianthicks.com/post/2017/07/27/state-of-elm-2017-results/
======
shakna
> JSON Decoders: This is one of those things that everyone has trouble with. I
> sure did! So I wrote a book about them. They’re not that bad once you get
> used to them!

This is odd thinking. Everyone hates the current JSON Decoders. That suggests
that there is something wrong with them, not that the audience should simply
"get used to them".

~~~
hellofunk
The "our way is the right way" mentality that is common in the Elm community
is really the larger issue here, and it has been a bit of a turn off for me.
There is a lot about Elm to really like, but it is a rather closed off
development culture without a lot of appreciation for hearing ideas and
experiences from others.

If Elm could open up and allow developers to experiment with other
architectures, like pretty much every other language, and not be so
restrictive in forcing everyone into the exact same pattern, I think it would
be very successful, because the language itself is nice. If someone wants to
use Elm as it currently is, that should be one simple option available to
everyone. But you should be able to easily discard that if you want to, and do
other things, including making a choice on the trade-offs for JavaScript
interaction. Languages that don't give developers much choice in how they are
used are usually not going to be very successful.

~~~
sridca

      The "our way is the right way" mentality 
      that is common in the Elm community is 
      really the larger issue here, and it has 
      been a bit of a turn off for me.
    

This is exactly how I felt as well.

I really enjoyed Elm in the beginning but soon hit the abstraction wall as the
complexity of my apps grew. I never got the impression that the Elm community
was going to fix those problems any time soon. I now use PureScript which is
far more pleasant to use, albeit it took a while to get up to speed with the
language.

Also I'm not the only one who went to PureScript from Elm:
[https://youtu.be/ngWo5e-294o?t=19m14s](https://youtu.be/ngWo5e-294o?t=19m14s)

~~~
rtfeldman
We're over 150,000 lines of Elm code in production and are loving it. Wouldn't
trade Elm for anything!

It's natural for people to have language preferences, but let's not pretend
there's some spooky "abstraction wall" prohibiting a nice experience at scale.
;)

~~~
hellofunk
That's great that you are having a good time. But a few points:

1) The experiences you've personally had do not capture all problems that
everyone has, and to assume you've seen it all is pretentious at best. You are
quick to dismiss the very idea that anyone would find limitations in the
language or its architecture, without even knowing the details of the myriad
other projects out there; sorry, that is just naive or arrogant.

2) I've noticed that on nearly any forum, you like to brag about the size of
your... codebase. The quality of a project and the problems it has solved are
not revealed in quantity of lines. It doesn't matter if you have 100K or now
you say 150K lines of code. I have no idea what problems you are solving, nor
you us; so stop hiding behind a nice round number and claiming it gives you
all manner of authority on what developers need.

> let's not pretend there's some spooky "abstraction wall"

Honestly, it's comments like this that underscore what many others here have
said about the general stance in the Elm community. How about actually
listening to people's experiences rather than dismissing them? You can't end
your comments with little emojis and pretend it washes over the general brush-
off you are presenting.

~~~
rtfeldman
> You are quick to dismiss the very idea that anyone would find limitations in
> the language or its architecture

I really don't think that's a fair reading of what I wrote. :)

> The quality of a project and the problems it has solved are not revealed in
> quantity of lines.

I totally agree! I was responding to a comment where the author said they
"soon hit the abstraction wall as the complexity of my apps grew."

Stating that we haven't hit any such wall in 150,000 lines of code provides a
concrete sanity check on that claim. Obviously I can't post our proprietary
code base, and I'd prefer to say something more objective than "we have a
_very_ complex code base." (Which I'd certainly say we do!)

> How about actually listening to people's experiences rather than dismissing
> them?

The statement "Elm has an abstraction wall" is not an experience report, it's
a claim about a language. I'm not dismissing anyone's experience by providing
a counterpoint to that claim.

I agree with you that nobody should tell others their experiences are invalid.
But I feel no obligation to slump my shoulders and say "yeah I guess you must
be right" if someone makes a misleading claim in a public forum.

> You can't end your comments with little emojis and pretend it washes over
> the general brush-off you are presenting.

I tend to write smileys whether I agree or disagree with someone. Sorry if
that bothers you. :)

~~~
hellofunk
Just yesterday on Slack some experienced members were pointing out the
workarounds necessary to handle certain challenging abstractions, things which
are still being thought about for future versions. It's perfectly valid to
admit there are some limitations there which may be too much for some
projects.

I don't think the above commenter's claim was any more misleading or vague
than your claim. Elm is not a general purpose programming language. It exists
for a single and specific use-case, a single design pattern, and this can be
fantastic for those who fit their projects into that world. But it is a
genuine side-effect of this that there are abstractions the language simply
does not make easy or possible as a result of its goals. That's fine, but it
can affect some projects -- obviously not yours. There are certain domains for
which Elm makes a lot of sense, and others for which it would be the wrong
choice.

And Elm as a language is still in search of its ideal abstractions, as they
have significantly changed over recent versions, so it's clear that this
experience is not unique to the commenter only.

Since Elm is just in its alpha stage, perhaps it is unfair to expect it to be
as capable and mature as alternative languages.

~~~
rtfeldman
> There are certain domains for which Elm makes a lot of sense, and others for
> which it would be the wrong choice.

No argument here!

Elm has this characteristic in common with JavaScript, Java, Scala, C, C++,
Python, Ruby, Perl, Haskell, PureScript, Go, Rust... ;)

> It's perfectly valid to admit there are some limitations there which may be
> too much for some projects.

Absolutely!

I know of one team that specifically switched from Elm to ClojureScript
because that made more sense for their project (whose purpose was to stitch
together JS libraries on the fly), and I thought they made the right decision.
ClojureScript was a better fit for their needs.

I also wouldn't use Elm in situations where a virtual DOM would be
problematic, such as making a large-scale rich text editor.

I don't think anyone would disagree with the broad claim that some languages
are a better fit for some projects.

> Elm as a language is still in search of its ideal abstractions

Also true of every programming language, except for the abandoned ones. :)

> I don't think the above commenter's claim was any more misleading or vague
> than your claim.

I'm not sure what claim you think I'm making.

I think I've been pretty consistent about pointing out Elm has led to some
great outcomes. I'm not saying things like "Everyone should drop what they're
doing and switch to Elm" \- that would be absurd.

I responded to an equally absurd claim by giving a counterexample.

Just as it's valid to point out that Elm (being a programming language) has
limitations, it's also valid to point out that people's preferences for
various programming languages aren't the same thing as universal truths.

If someone wants to say "I tried both Elm and PureScript and preferred the
latter," that's great! Everybody is happy with the language they're using. We
all win!

If someone wants to say "I switched from Elm to PureScript since nontrivial
Elm apps can't exist because abstractions," it's fair for me to demonstrate
the absurdity of that claim by pointing out that our 150,000 line Elm app
exists.

~~~
sridca

      If someone wants to say "I switched from Elm to PureScript 
      since nontrivial Elm apps can't exist because abstractions,"
      it's fair for me to demonstrate the absurdity of that claim
      by pointing out that our 150,000 line Elm app exists.
    

It would appear that you misunderstood what I said.

Elm not facilitating the use of sufficient level of abstractions does not
necessarily mean one cannot use Elm to write the said app. It simply means
that you would have to deal with it all at a lower level (with the
corresponding code duplication where necessary) in the absence of the
aforementioned capability to build abstractions. For more on this topic refer
to
[https://en.wikipedia.org/wiki/Structure_and_Interpretation_o...](https://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs)

Furthermore, in the process of agreeing with the parent comment, I was also
stating that I had never got the impression that the Elm community was going
to fix those problems any time soon. This was because the community leaders/
members were often quick to dismiss any suggestions/ complaints offered
instead of patiently exploring them. Indeed your characterizing of this thread
as talking about some `spooky "abstraction wall"` is a testament to that.

Speaking personally, those were the two-fold reasons (both technical and
social) for me to switch to PureScript for my personal projects. I still think
Elm is pleasant to work with and to that extent I am continuing to keep track
of its progress.

~~~
rtfeldman
> It would appear that you misunderstood what I said.

Could be. The point of the paragraph after this seems to be self-evident (if
an abstraction is unavailable, then you use a lower-level alternative). If
that was what you meant, then I agree...and I don't think I needed to have
read SICP to know that. ;)

> This was because the community leaders/ members were often quick to dismiss
> any suggestions/ complaints offered instead of patiently exploring them.

I would describe this particular issue as having been "patiently explored to
death." Here are several links demonstrating this:

[0] [https://groups.google.com/d/msg/elm-
discuss/oyrODCgYmQI/T2I_...](https://groups.google.com/d/msg/elm-
discuss/oyrODCgYmQI/T2I_8L-AL6EJ)

[1]
[https://www.youtube.com/watch?v=oYk8CKH7OhE](https://www.youtube.com/watch?v=oYk8CKH7OhE)

[2] [https://github.com/elm-lang/elm-
compiler/issues/1039](https://github.com/elm-lang/elm-compiler/issues/1039)

[3] [http://faq.elm-community.org/#does-elm-have-ad-hoc-
polymorph...](http://faq.elm-community.org/#does-elm-have-ad-hoc-polymorphism-
or-typeclasses)

> Elm not facilitating the use of sufficient level of abstractions [...] I had
> never got the impression that the Elm community was going to fix those
> problems any time soon. [...] Indeed your characterizing of this thread as
> talking about some `spooky "abstraction wall"` is a testament to that.

This quote characterizes Elm as not having "sufficient level of abstractions"
and that these are "problems" that are not being "fixed." My reference to the
"abstraction wall" is also a direct quote from a previous comment. [4]

All of these quotes frame personal preference as objective fact.

It's like saying Java is "broken" because it does not support manual memory
management, which no one seems "interested in fixing" by adding `malloc()` and
`free()` to the language. Plenty of people would (rightly!) be upset if Java
introduced `malloc()` and `free()`, thus breaking the invariant that
everything is garbage collected.

Likewise, there are many happy Elm users, myself included, who think Elm would
be _substantially worse_ if it moved toward the abstractions that PureScript
embraces. The fact that Elm doesn't is a benefit from our perspective, even if
it's a drawback from yours.

Neither of us have "wrong" preferences. There's no universally correct answer
here. We can both go about building Web applications in our languages of
choice.

This distinction may not matter to you, but to someone wondering whether Elm
is worth looking into, there's a big difference between "I am inevitably going
to hit a wall" (which is not true) and "not everyone agrees with Elm's design
decisions" (which is of course true).

[4]
[https://news.ycombinator.com/item?id=14877406](https://news.ycombinator.com/item?id=14877406)

~~~
sridca
The level of abstraction a programming language provides is a verifiable fact.
At what minimum level a programmer is comfortable working with is a personal
preference. If Elm’s type system is not sufficient to provide that level of
abstraction it is certainly a problem to me that has not been resolved in the
language. For all we know, other people may have different preferences; some
may be content working with vanilla JavaScript and some even with assembly
instructions. I don’t think anyone denies this, and you seem to be defending
something that was never challenged.

As for Elm’s approach to dealing with discussions of this nature, out of the
four links you had provided the last three were unilateral messages (the
Github issue in particular is locked to collaborators with only a message from
Evan). As for the Google Group thread it perfectly demonstrates the feeling I
have had with the Elm community. Paul Chiusano (who had the same problem as
me) in that thread finally got frustrated due to lack of patience and
exploration among the participants; it is quite odd you would use this as a
demonstration of the Elm community patiently exploring something. His exact
words:

    
    
      What I find frustrating about this is that when 
      conversations get ugly, the actual issues are not 
      given sufficient attention and people just end up 
      responding to the general unpleasantness and the 
      labels being tossed around. I still feel like we 
      have not really gotten to the bottom of things, 
      but I don't have much hope that this thread will 
      get us there and would rather just drop it for 
      now like Joey suggests.

~~~
rtfeldman

      At what minimum level a programmer is
      comfortable working with is a personal
      preference. [...] I don’t think anyone denies 
      this, and you seem to be defending something
      that was never challenged.
    

Since it sounds like we're in agreement on this being a matter of personal
preference, I'm happy to move on. :)

    
    
      Paul Chiusano (who had the same problem as me)
      in that thread finally got frustrated
      due to lack of patience and exploration among
      the participants; it is quite odd you would
      use this as a demonstration of the Elm
      community patiently exploring something.
    

Paul wasn't frustrated due to a "lack of patience and exploration among the
participants," he was frustrated that "let's be patient and explore this
further" was the outcome of the discussion--instead of the outcome he wanted,
which was getting his feature requests being prioritized higher. I'll break it
down.

First, here is a quote from Evan's first response in that thread: [0]

    
    
      Since very very early on, type classes have been
      requested by Haskell programmers. My opinion is
      that these features create serious accessibility
      problems in Haskell, even for people such as
      myself who came to Haskell already knowing
      Scheme, Standard ML, and OCaml. I was three
      years in to Haskell before Monad Transformers
      were clear to me.
      
      So I have always looked at these things not just
      as features to be implemented, but unsolved
      design problems. How do we present these ideas
      in a way that is super simple?
      How do we grow our community in a smart way?
      
      A question to think about for type classes is,
      what is the best way to reuse variable
      names? Type classes, implicit arguments, and
      module functors all answer this question,
      but each comes with some unfortunate tradeoffs.
      My view here is that there is no need
      to rush. When our community collectively needs
      this kind of feature, we will be in
      a much better position to evaluate the
      trade-offs between these approaches for the
      problems we are facing in practice.
    

Some things to note:

1) He asks specific questions to invite exploration. "What is the best way to
reuse variable names? How do we present these ideas in a way that is super
simple? How do we grow our community in a smart way?"

2) He explicitly calls for being patient with that exploration: "My view here
is that there is no need to rush."

Following this are a bunch of posts which include a mix of discussion about
these questions and a debate about prioritization.

Paul then posted: [1]

    
    
      This is turning into an interesting discussion
      and I'm very tempted to wade in,
      but honestly, I'd just like an answer to my
      earlier question about timeline for
      the non-controversial features.
    

He's being incredibly clear about this: he found the exploration interesting,
but was more interested in knowing Evan's timeline than participating. Fair
enough.

At this point we can rule out the conclusion that Paul "finally got frustrated
due to lack of patience and exploration among the participants" \- because he
stated, in no uncertain terms, that despite being tempted by an interesting
discussion, that's not what he wants. What he wants is an answer about the
prioritization of his feature request.

Evan responded, and Paul responded back: [2]

    
    
      Okay, thanks for the reply. And I appreciate
      all the hard work you are putting into Elm!
      [ ... ] Here's something to consider when
      prioritizing work [ ... ] Features like HKP +
      rank-N types / typeclasses are like an
      investment in the whole community, and they
      can have huge leverage.
    

So he's not interested in participating in the discussion, or in directly
answering the questions Evan posed at the start of the thread, but he still
wants Evan to accept his feature request. I get that, but I'm not sure how the
person who is essentially saying "I do not want to participate in a patient
exploration with the community, I think these features should be added as soon
as possible" can be held up as supporting evidence for the notion that the Elm
community is closed to patient exploration.

Later, about 50 posts deep in this thread, an Elm community member named Sean
finally got frustrated with how someone else named Jonathan was advocating for
his (and Paul's) point. Sean quoted Jonathan's comment that "I find it very
hard to believe that you have all the requisite understandings and yet still
reject these ideas" and responded by saying "And this is exactly the sort of
condescending stuff that puts people off the Haskell community. As soon as
someone doesn’t agree with you, you question their ability. Lovely." [3]
Jonathan responded "So I think we have our answer-- no, you don't even
understand what you are rejecting. Brilliant."

This obviously heated exchange was what led Paul to write what you quoted,
which I'll re-quote with additional context of Paul's comment: [4]

    
    
      Jonathan, I share some of your frustrations
      but I think you should be much more careful
      in how you say things. [ ... ] Sean, whether
      or not you think your characterizations of
      Jonathan are accurate, I think some of your
      comments were unhelpful and uncharitable
      toward Jonathan.
      
      [ ... ]
      
      What I find frustrating about this is that
      when conversations get ugly, the actual
      issues are not given sufficient attention
      and people just end up responding to the
      general unpleasantness and the labels
      being tossed around.
    

So he's frustrated that this heated exchange got in the way. The rest of what
you quoted was:

    
    
      I still feel like we have not really gotten
      to the bottom of things, but I don't have
      much hope that this thread will get us there
      and would rather just drop it for now like 
      Joey suggests.
    

As Paul made extremely clear in the quote from earlier, what he's talking
about here is that he wants Evan to accept his feature request. He's not
saying he felt there was insufficient exploration; in fact, he thought that
exploration was "an interesting discussion and I'm very tempted to wade in" \-
his objection is that the discussion's outcome - "be patient; this is an
unsolved design problem and we need to gather more real-world data points
before we can solve it" \- was not the outcome he wanted.

To recap:

1) Evan calls for patient exploration

2) Some patient exploration happens

3) Paul comments that the exploration has been interesting, but it's not what
he wants. Really what he wants is a timeline for when the features will be
prioritized.

4) Much later in the thread, two commenters get upset at one another.

5) Paul expresses frustration that their getting upset is distracting the
thread from what he wants, which is to get his feature request accepted.

Hopefully this clears things up. :)

[0] [https://groups.google.com/d/msg/elm-
discuss/oyrODCgYmQI/T2I_...](https://groups.google.com/d/msg/elm-
discuss/oyrODCgYmQI/T2I_8L-AL6EJ)

[1] [https://groups.google.com/d/msg/elm-
discuss/oyrODCgYmQI/dwvw...](https://groups.google.com/d/msg/elm-
discuss/oyrODCgYmQI/dwvwD7yYX68J)

[2] [https://groups.google.com/d/msg/elm-
discuss/oyrODCgYmQI/qf_9...](https://groups.google.com/d/msg/elm-
discuss/oyrODCgYmQI/qf_9ETPgsvoJ)

[3] [https://groups.google.com/d/msg/elm-
discuss/oyrODCgYmQI/_i-o...](https://groups.google.com/d/msg/elm-
discuss/oyrODCgYmQI/_i-opQnpgCcJ)

[4] [https://groups.google.com/d/msg/elm-
discuss/oyrODCgYmQI/H9NG...](https://groups.google.com/d/msg/elm-
discuss/oyrODCgYmQI/H9NG31Q6ONIJ)

~~~
hellofunk
Wow, now that's what I call a decompilation.

------
fnordsensei
> Aside from the huge number of JavaScript programmers, the top 5 are Ruby,
> Python, Haskell and Java.

> No functional language beside Haskell cracked the top 5. I’m a little
> surprised by this: I had expected to see more people with functional
> programming experience.

Perhaps Elm provides less "news" to people who are already using one
functional platform or another, and therefore lower incentive to try it
out/switch?

~~~
Tarean
For haskell programmers there is also purescript which is basically a somewhat
cleaned up haskell that compiles to human readable javascript.

------
the_duke
From looking at the repositories, I get the feeling that Elm devopment effort
has been pretty low for quite a while.

Many pull requests and issues are undiscussed and uprocessed.

~~~
hellofunk
Elm's primary development largely operates on the whims of a single person.
This can have both advantages and disadvantages, and in my opinion is a net
negative.

~~~
steinuil
I think the advantages of depending on a single person only come out when that
person has a clear vision of where they want to bring the project.

I feels like Evan doesn't know what to do with the more advanced features that
Elm, in my opinion, desperately needs, and I've been pretty unhappy with how
he's taken a policy of removing stuff because nobody uses it.

~~~
hellofunk
The other problem is that no matter how many times different people bring up
the same recommendations for Elm language features, if those opinions are not
shared by Evan, they are seen as trivial and unnecessary.

Also, for such a very tiny community, they make it hard to participate in some
ways. Many of the github issues are locked for comments unless you are a core
contributor. And the mailing list has a lengthy waiting period on the first
several new messages sent to it (I've never seen such a tightly moderated list
in any language). You would think they would want to embrace anyone who
chooses to spend time with their language, but they don't really give average
users much of a voice.

~~~
tgecho
There are many decisions about Elm (the language and the development process)
that I'm personally not crazy about. However, with so many asking "why are
open source maintainers burning out?" I think it's a bit obnoxious for us as a
community to criticize someone's chosen style for working on their free gift
to us all.

~~~
hellofunk
The issue is that after awhile, a language should not be an individual
person's gift to the world. It's a tool, after all. People and companies use
and depend on it; users should be given greater freedoms or voices. It's not a
piece of art to marvel at; it's something to be tugged on by many angles to
create real work by people other than the language author.

In most languages, like C++, Javascript, Clojure, Elixir -- you find a single
person who created the language, and then the real guts of how the industry
actually uses it are the results of a large community; the original author
usually isn't the sole source of best practices.

------
tarr11
JSON Decoders were the killer for me. Just way too verbose.

~~~
enalicho
Luckily there's a whole range of tools dedicated to making your life there a
bit easier:

\- json-to-elm [http://json2elm.com](http://json2elm.com)

\- swagger-elm [https://github.com/ahultgren/swagger-
elm/](https://github.com/ahultgren/swagger-elm/)

\- elm-graphql [https://github.com/jahewson/elm-
graphql](https://github.com/jahewson/elm-graphql),
[https://github.com/jamesmacaulay/elm-
graphql](https://github.com/jamesmacaulay/elm-graphql)

\- elm-export [https://hackage.haskell.org/package/elm-
export](https://hackage.haskell.org/package/elm-export)

And so on :) While it would be nice to solve Json Decoders in a better way,
these solutions are very helpful for the time being.

------
dom96
It's great to see so many programming language community surveys these days.
I'm running a survey for the Nim programming language and I'd love to hear
your responses: [https://nim-lang.org/blog/2017/06/23/community-
survey-2017.h...](https://nim-lang.org/blog/2017/06/23/community-
survey-2017.html)

------
op00to
Before reading the article, I was really excited to read about people still
using Elm (the email client) in 2017. There's enough people using Elm to
justify a State of Elm in 2017? Awesome! I was disappointed.

------
crimsonalucard
I was trying to build a tmux style svg based windowing system for elm. Guess
what? this involves a tree. Trees don't go well with functional programming.
Ever heard of a zipper? lol.

~~~
gilmi
> Trees don't go well with functional programming

What? Building trees is easy as pie in typed fp

[http://hackage.haskell.org/package/containers-0.5.10.2/docs/...](http://hackage.haskell.org/package/containers-0.5.10.2/docs/Data-
Tree.html)

> Ever heard of a zipper?

[https://github.com/soupi/purescript-list-
zipper/blob/master/...](https://github.com/soupi/purescript-list-
zipper/blob/master/src/Data/List/Zipper.purs)

