State of Elm 2017 Results | Hacker News Reader

State of Elm 2017 Results

brianthicks.com

83 pointsmyth_drannon73 comments

> 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".

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.

> it is a rather closed off development culture without a lot of appreciation for hearing ideas and experiences from others.

I've had the opposite experience. From what I've seen, Elm's development culture requires hearing outside ideas and experiences, to a greater degree than I've seen in any other programming language community.

Many design discussions get blocked on Evan saying "We need to research what's out there more before we can proceed. What do other languages do? Which approaches have people liked and disliked? What are the trade-offs of each approach?"

It slows down development, for sure, but I think it's worth it. :)

  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

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. ;)

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.

> 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. :)

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.

> 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.

  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...

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.

> 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_...

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

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

[3] http://faq.elm-community.org/#does-elm-have-ad-hoc-polymorph...

> 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

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.

  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_...

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

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

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

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

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

Count me among the converts who moved from Elm to ClojureScript, and I'm loving the FP as much as ever. I like quite a bit about Elm, but the main issue came down to productivity and workflow. You can do the same things in either language with the proper time, but Elm requires a lot of extra code and effort to so some simple things, and much is not obvious. When discussing things with other Elm developers, they would tell me "there's not good way to do that now, but here are some hacks to get it to work; hopefully this will change some day." And I hit that time and time again. If you've used Elm for a long time, maybe you already know all the hacks, but I found it disruptive to my flow. With ClojureScript, I do spend a little more time dealing with the occasional console error, but this is a lot less time than having to find the tricks to do certain things in Elm. I can appreciate the goal of purity and rigid typing in Elm, but it definitely came at a cost in development time. My ClojureScript apps are about half as much code and at least half the time spent writing them. One of them currently has about 2000 users and not one has sent a report of any runtime crashes, so I think the frequently-cited horror of runtime problems is somewhat exaggerated when justifying the strong restrictions Elm imposes on the development process (and for what it's worth, you still get runtime exceptions in Elm, just maybe a few less than in other languages). Someone recently posted in the Elm Slack a screenshot from the Chrome console of a live production app with many users that started throwing runtime stack overflow errors on a recent version of Chrome. Apparently it was caused by another of these non-obvious problems that required he break up certain lists into concatted lists instead, which was not idiomatic but necessary for the Elm runtime.

Anyway, that's just my $0.02. With ClojureScript I still get all the functional idioms and immutable data and persistent collections, and it has a deeper and more interesting core library for FP that really lets you abstract data manipulation in creative ways, which is a great bonus.

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

You are throwing some hyperbole around here. We are discussing the shifting foundation for abstractions in Elm, and I'm pointing out that Elm is a young language that has changed its design patterns significantly in the last year or two, the language is not so mature yet, and is probably years from 1.0 stability. That's a perfectly valid point to make in any discussion about the language's design choices. Your blanket generalization about all programming languages is perhaps your way of agreeing with some developers' frustrations in Elm. It kind of reminds me of the Steve Jobs' excuse during the iPhone 4 antennagate when he slyly admitted to the problems by saying "look, all cell phones have problems."

> Elm is a young language that has changed its design patterns significantly in the last year or two

In the past 2 years there was one big change (0.16 -> 0.17) that said "instead of being best practice, the Elm Architecture is now the only way to do it." [0] Every other release has not meaningfully affected design patterns as far as I can remember.

That said, I agree that it's fair to consider "removing alternatives to the best practice" a significant change of design patterns. For for those who had been following different patterns, I know it was a big change.

You're also right that Elm is a young language, and there's inherent risk of change that comes along with that. :)

> perhaps it is unfair to expect it to be as capable and mature as alternative languages.

I don't want to claim Elm is flawless, or for that matter stable and mature—because right now it's none of those things. Sure, it's been battle-tested and proven more than capable, but of course that's not the only factor in choosing a language.

I would note that from what I've heard, among functional altJS languages Elm is second in maturity only to ClojureScript. (I base that on conversations I've had with users of CLJS, PureScript, ReasonML, GHCjs, and ScalaJS.) As far as I can tell, the only other "alternative language" that's more mature than Elm is JavaScript itself—or maybe TypeScript, if you count that as a separate language.

To be clear, what I do want to claim is that Elm is a strong choice for typical web applications. That's true of small ones, medium-sized ones, and especially big ones.

Again, when I make that claim, I'm not saying that everyone should choose Elm for their project. Projects differ, and people have preferences. Elsewhere in this comment thread is someone who preferred ClojureScript, and someone else who preferred PureScript. Great! :D

What I'm saying is that nobody should be concerned about whether Elm applications can scale well. They already have scaled well for plenty of projects. There clearly is not some "abstraction wall" that prevents this from happening, and people having personal preferences for other languages' design choices doesn't imply otherwise. :)

[0] http://elm-lang.org/blog/farewell-to-frp

> ...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.

javascript already lets you do whatever you want, whenever you want. evan's goal isn't to be 'javascript with different keywords'; he wants to create something with a specific set of properties.

a language doesn't need to be all things to all people. runtime guarantees are a core part of elm's identity. if you want to introduce null and undefined, there are plenty of other options.

This has also been my experience. Elm programmers don't tolerate dissent. The community is welcoming so long as you toe the line.

That's not particularly true. I am one of the most vocal dissenters when it comes to Elm. Dissent is welcome, as long as it's constructive. Saying "I don't like 4 spaces" is about as constructive as saying "I don't like Emacs". There are reasons as to why every piece of Elm is how it is. It is an opinionated language, that is very true. If you try to do things that don't fit well into Elm, you are going to have a hard time, simply because of those opinions that are built in. The community is eager to discourage people from falling into those common pitfalls. Everyone is welcome, however.

Come say hi on Slack! People there will help you judge if Elm is for you. If it's not, that's a shame. If it is, great!

I'm not sure what the last sentence is supposed to mean. Can you link to an example of what you're referring to?

Have a look at this thread right here: https://news.ycombinator.com/item?id=14873351

This links to a thread where an Elm community member politely explains design decisions.

What am I missing?

Dang you beat me to it. Pretty funny that sibling comment spawned a perfect example.

I don't think that is a fair evaluation of that comment thread. I explained with links and resources _why_ elm-format is how it is, and _why_ it is considered a feature to not have flags. I also backed this up by showing how many of the users enjoy elm-format. This is not saying "don't dissent". This is saying "this argument is a strawman"

i'm not sure i understand how that is a 'perfect example' of 'don't tolerate dissent'. could you elaborate?

I noticed a similar problem when I wanted elm-format's indentation set with 2 spaces instead of the un-configurable 4.

Please see the discussion at https://github.com/avh4/elm-format/issues/210. A fixed indent size is a feature, not a bug. Making a single tool that everyone uses is so nice. No need to mess around with .eslint files or the like.

It might have been fine if elm-format had chosen better defaults.

Go chose tabs over spaces which are configurable in your editor, so everyone wins. Elm has other awkward style choices, like 'comma-first', and excessive line-breaks in-and-around statements. If they had less obnoxious defaults, people might be less bothered about this issue.

And honestly, as a dev you work at a company for what, 3 months minimum. How hard is it to setup a .eslint file, vs. having to always write code in a style you don't enjoy.

Universal consistency of code format just isn't that important, consistency within a team or company is what matters, and you don't lose that by allowing configuration.

The interesting thing to me is that you highlight how priorities are different among different people/companies; to me, choice of indentation spacing is trivial. But to you and the sibling comment, it obviously is not. And that's the point: a developer should be respected to decide what is important for their work. In this case, we are talking about indentation flexibility. But this problem scales throughout on many other issues that I might find important but you do not. Most languages give developers more freedom, even if starting out with a consistent default that everyone can understand first.

Elm is an opinionated language. The framework comes built-in. The tooling comes built-in. A clever language designer once said "there is only one way to do it". Elm is that, but at the language level. Elm-Format is opinionated, and for people who love Elm, they also love that.

> It might have been fine if elm-format had chosen better defaults.

Subjective. This is a time old discussion. Please read the linked issue.

> Universal consistency of code format just isn't that important, consistency within a team or company is what matters, and you don't lose that by allowing configuration.

When I come to an Elm project, I am able to read the code instantly. In fact, the majority (91%) of the Elm community who use elm-format enjoy it because of this. See here: https://www.brianthicks.com/post/2017/07/27/state-of-elm-201...

What you say might be true for you, but for people who are actually writing and using Elm, it does not apply.

> for people who are actually writing and using Elm, it does not apply

You assume the OP is not actually using the language.

> You assume the OP is not actually using the language?

I'm making generalizations based on their statements -- the stats and anecdotal evidence tells us things about how the community at large.

> And yet you yourself said in another comment that you do not use the language.

Can you link that comment? I think you've gotten me confused with someone else -- I'm a very active member of the Elm community and write Elm as part of my day job and have done for over 2.5 years.

I updated my comment; indeed I was confusing you with another commenter, my apologies.

I'm not sure how you are so confident that the user "allover" is not actually using Elm, though.

I'm not really making assumptions about their use, but more rather commenting on the feeling of the community as a whole. I basis this on my deep involvement and the stats that we have to hand. I know that Elm format is not considered an issue by a large majority of Elm users. In fact, I can only thing of a couple of people who dislike it. So while they might personally use Elm and dislike it, it is not representative of the community -- it's important not to spread FUD, as comments on HN often tend to. The people who are most vocal about elm-format being negative are those who have not actually used it outside of short trials.

Comma-first makes sense since you're chaining off the right-hand side of an expression more than most other languages, e.g. with |> operators.

That decision will probably save man-years of wasted time spent managing a trailing comma.

Elm's JSON combinators are great.

I'm sure one reason so many people have particular trouble with them is because, according to the survey, the vast majority of them come from a dynamically-typed language where you'd just go `user = JSON.parse(string)`.

I think a lot of people would be helped by tacking a bunch of real-world examples onto the actual Json.Decoder docs like how to decode `[1, [3, 5], 7, 9]` (nested range) into `[1, 3, 4, 5, 7, 9]`. One issue is that it's pretty hard to derive understanding from just function signatures, so a dozen quick-start / cookbook examples gives people something to chew on.

Combinators are really good at forbidding runtime errors which is a central theme of Elm, but it comes at the expense of a steeper learning curve than the weaker alternatives that come to mind: reflection and manual descent.

> Elm's JSON combinators are great.

> I'm sure one reason so many people have particular trouble

Those two sentences don't really fit together. Elm isn't an academic experiment, which means people need to use it.

If the vast majority of people find it overly difficult, then it probably is.

> come from a dynamically-typed language where you'd just go `user = JSON.parse(string)`

Not just dynamic languages.

Haskell, one of Elm's inspirations, can handle it a hell of a lot easier.

Define an interface, then use it on a string:

    data Coord = Coord { x :: Double, y :: Double }
                 deriving (Show, Generic)
    let req = decode "{\"x\":3.0,\"y\":-1.0}" :: Maybe Coord

I am cheating a bit, as that's the aeson package... But decoding the JSON is a lot simpler than the Elm equivalent, and Haskell doesn't even target web browsers, where JSON is so prevalent.

But, here's another static example, this time, C++.

    auto j3 = json::parse("{ \"happy\": true, \"pi\": 3.141 }");

You can use auto to avoid writing a massive type definition, or you can write it ensure it's correct.

Static typing has nothing to do with not being able to write JSON.parse(string), because it doesn't prevent that. At all.

I've heard more than one person argue against automatically generated encoders/decoders since it's easy to accidentally introduce breaking changes to your API by renaming a record field / class method.

If that's your view then Elm's approach is a plus for the language since it eliminates a potential pitfall.

> argue against automatically generated encoders/decoders since it's easy to accidentally introduce breaking changes to your API by renaming a record field / class method

Can anyone further substantiate this argument, I feel like it's not very strong as is.

Haskell's way of pre-defining an interface handles that, with less than a quarter of the boilerplate.

You've given some toy examples, but in the real world you're writing custom decoders. For example, when interoperating with any API that you didn't write.

Your example would lead us to believe that nobody is writing custom decoders in Haskell that look like Elm's decoders, and that's... very misleading.

I posted this lower down, but I'm posting it here again since it also applies to your comment:

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

- json-to-elm http://json2elm.com

- swagger-elm https://github.com/ahultgren/swagger-elm/

- elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql

- 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. Long term, I personally believe the right route is hard to decide on. We could go with json-decoders being part of the language and compiler itself. We could generate decoders from type aliases. Or some template solution like template Haskell. Or tagged unions like Go. The issue is that decoders are not a blocker to people who write a lot of Elm. They make me sad, but they're not a blocker. That means that the solution is not such a high priority.

I don't think that sentence you quoted suggest everyone should get used to them. It simply says they're not that bad once you get used to them.

> It simply says they're not that bad once you get used to them.

Yes, and I was simply pointing out that, that is not helpful thinking.

JSON is fundamental to working with the web, and Elm works on the web.

A high learning curve on something fundamental is fine in languages that are academic in nature, intentionally obtuse, or designed to be difficult. It's not fine in a language intended for production use.

This post was about a language survey.

It says that JSON decoders are too hard for the audience.

A helpful step forward, is seeing how to make them less obtuse. An unhelpful step backward, is tell everyone just deal with it.

We'll see which step Elm takes in the coming months.

> 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?

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

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.

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.

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.

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.

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.

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.

I believe he is paid full time to work on elm. I might be wrong. But if so burn out should be less of an issue.

I can understand your perspective, but frankly I don't think opening it up would add much value for anyone. He clearly has his own vision, and opening up wider discussion just bogs him down in pointless extra work from his viewpoint. He'd rather just get stuff done, and I think that's a reasonable viewpoint. Nothing stopping you or anyone else from forking Elm if you don't like how things are going.

> wider discussion just bogs him down in pointless extra work

> Nothing stopping you or anyone else from forking Elm if you don't like how things are going.

Comments like this are what supports the points I've made here. It's just an attitude I have not seen in other language communities, for better or worse.

Discussions about language design and direction are not usually seen as "pointless."

I don't even use Elm. I have literally zero vested in Elm, just a passing interest.

This is just the reality. He created Elm to use. If others find it useful, great, but why he would he get bogged down in discussing the minutia that always arise in such communities?

Use his work, fork it, or move on. He's clearly not interested in the types of discussions you're interested in having. Why is that wrong?

Maybe it's less than ideal if you want to grow a big community, but again, maybe that's not his goal. He just wants to use it, remember?

> He just wants to use it, remember?

It was recently pointed out somewhere (maybe the Elm mailing list) that Evan does not actually touch a production codebase in Elm often.

Yep, there is very little discussion over taking the language in other directions, because ultimately Evan supposedly knows best. It's sad to see such a nice project being bogged down by such a mentality, but Evan really brought this upon himself.

Like the post says, come talk on Slack. That is where the majority of discussions happen.

I would like to voice that there are people who find slack not very good for very active communities.

On the one hand it's a real-time chat, on the other hand it always feels like you are missing out if you are only opening the app now. But you also can't just leave a message and come back later because the scrolling is awful and everyone has probably just moved on from that conversation.

I really prefer IRC + log and something like reddit/mailing lists over slack and have recently stopped interacting with a community that have all moved to slack.

We have a fully searchable and linkable archive for the Elm Slack, actually. :)

Elixir doesn't (yet) seem to be suffering from this despite having a Benevolent Dictator

Not quite. Things are happening, but perhaps not in the way you'd expect. See https://github.com/elm-lang/projects/blob/master/roadmap.md#... for roadmap notes, and some more notes on how issues are handled in Elm: https://github.com/process-bot/contribution-checklist/blob/m...

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

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

- json-to-elm http://json2elm.com

- swagger-elm https://github.com/ahultgren/swagger-elm/

- elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql

- 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.

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...

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.

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.

> 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/...

> Ever heard of a zipper?

https://github.com/soupi/purescript-list-zipper/blob/master/...

Trees go extremely well with FP. In fact, a lot of Elm's core data structures are implemented with trees. Dicts, Arrays, Sets. Here's an example of a zipper package in Elm: http://package.elm-lang.org/packages/wernerdegroot/listzippe...

I used to think that walking trees was a standard task in functional programming languages because the one I am used to (Clojure) contains gobs of functions in its library for all kinds of walking, zipping, combining, separating trees of different structures. But I've learned since studying other functional languages that it isn't as commonly done as I'd thought.

Reply on news.ycombinator.com