Hacker News Reader

Comment by rtfeldman | Hacker News Reader

Honestly I think the main reason for this perception is that people in the Elm community have gotten increasingly tired of correcting inaccuracies people like to post about Elm on Hacker News.

I spent a bunch of time doing that in the past, and eventually stopped because I felt like Sisyphus. The same people would crop up on the next thread repeating the same things anyway. Of course if the claims go unchallenged, it leads to the perception that they're accurate...but that doesn't make engaging with them any more enjoyable a way to spend one's free time.

If you want to check the health of the Elm community, visit Elm Slack and ask in the #beginners channel how people feel about it. It takes about the same amount of time as posting a HN comment, but it gives a very different perspective than the one you'd get if your main source of Elm information was Hacker News comments! :)

http://elmlang.herokuapp.com/

View on HN

Speaking as someone who liked Elm for a while, then abandoned it, I will say that the biggest problem with the language is absolutely its leadership. Development moves at an absolutely glacial pace and basically takes place with no transparency at all. I would argue that it's more like a "source available" project than an "open source" one since the core dev team is so exclusionary. Most planning takes place inside Evan's head, leaving others to just speculate as to what's going to happen to the language.

On top of this, the community is run like a dictatorship. Dissent is silenced and banned, and faux positivity is spread far and wide. I got sick of it and was banned from the Elm subreddit after I expressed my frustration. That's pretty much when I gave up on the language, years ago, on version 0.18 (fwiw, they're on version 0.19 now, that's how slow updates are)

This is an example of the type of post I was referring to being tired of correcting.

I don't use Reddit anymore, but if memory serves there have been about 5 people total banned from the aforementioned Elm subreddit, which is fewer than 1 ban per year it's existed.

I invite anyone to evalute the accuracy of "Dissent is silenced and banned" with that data point in mind, and to evaluate the accuracy of the other above claims accordingly.

Interesting food for thought. I bought your book awhile back and was 2 chapters in before reading about the aforementioned "Dissent is silenced and banned" issues which led me to abandon continuing at the time. Maybe I'll jump back into it.

I've not heard of such misinformation being spread about other languages. Id love to hear your side on why Elm itself seems to attract such ire if its inaccurate.

It's a great question!

I think there's more than one factor, but the biggest one comes down to setting expectations, especially in the early days.

Elm does a lot of things differently than other languages, and while I think that overall those differences have been instrumental to its success, especially early on it sometimes wasn't clearly enough communicated when "this is temporarily different because it's a WIP; you can expect it to be more like what you're used to in the future" versus "this is different by design, so expect it to stay different or even to become more different."

Examples of this include typeclasses (a lot of people coming to Elm from a Haskell background assumed Elm would add them as a matter of course), JS interop (by design, it's not a traditional FFI, although there was an unintended backdoor that kind of worked like one; when that backdoor was finally removed, after much communication that in retrospect should have happened at the outset, some of those who had been relying on it were understandably upset), how the project is run (more like Clojure than like JavaScript), and what the release schedule looks like (batching large projects rather than more frequent smaller releases).

I think things are a lot clearer today, but for some it's unfortunately too late to make a difference.

One thing is that it wasn’t communicated that well, but other (and that’s what made me feel really uncomfortable) is that it felt like „This feature is not allowed anymore - except for some dudes, they’re cool enough and can use it” (e.g. native modules, operators). Either keep or drop feature

Kernel code and custom operators are only allowed under elm/ and elm-explorations/, so only 7 core packages can use them. The core developers cannot use those features in projects like everyone else.

And who can contribute to `elm` and `elm-explorations`? The 7 cool dudes.

The Elm contributor circle is a clique that you literally have to be a strong contact with one of the contributors to get into it. It goes against everything open source stands for.

> It goes against everything open source stands for

Sorry, that's not correct. It goes against your opinion of what open source should stands for, and many projects run in a way where everyone can contribute. But, it's not the only way.

The license determines how the code comes, that's the only rule. There's no rules about how a community must run. It's for the code creator (maintainer) to determine how or even IF they want a community of contributors. There's lots of ways of doing open source!

And saying it's not "open source' if you don't do X outside the license is just a No true Scotsman.

Open source is a development methodology. The license is the bare minimum.

The problem is there are some reasonable features that cannot be implemented with the current ports system that _should_ fit into the expected design. Specifically, I feel you should be able to replicate the `Http` module using ports or some other available system. However, you cannot properly dispatch a task and then tie together the result with a curried `Msg`, as you might expect or hope [unless you store a complex state object in your model]. These types of issues are the frustrations that, I believe, cause some discontent in the community. I feel more people understand why you should not, per se, make random FFI calls in the middle of pure code (e.g. since it would break dead code elimination and require evaluation order guarantees), but other restrictions seem arbitrary.

The thing I found unsettling wasn’t that something was disabled (fair design decission), but the mindset that considers some features harmful , but is happy enough to use it in its own „special case projects/packages”. It doesn’t really matter for how many packages its available, since it can be changed on a whim. I can only speak for myself, but I found it unfair and patronizing

I don't think that's fair. If elm ever wants to replace js it only needs to rewrite the kernel modules, they govern. Otherwise the whole ecosystem would break in that case and yes, that would be a harmful feature.

I didn’t mean locking features, especially native modules - didn’t write a single one, so personally I won’t miss it. I meant „some repos are more equal then other” mindset. It’s clearer in case of custom operators - they are considered confusing, unless you mean parsing and by parsing you mean elm/json or elm/url, then it’s cool.

By all means, I’m not saying those are crucial features or that they don’t have right to do whatever they want with their language. They can and they do. I just find this kind of atitude and reasoning patronizing.

FWIW, I have the same experience as the parent poster. I used to love Elm, evangelized the architecture, wanted to write Elm professionally. I was constantly bumping into things that were not finished or working, but didn’t really mind. But I also often encountered cases where the leadership team was saying “we don’t want this discussion here, thank you very much”, even if the discussion was perfectly legitimate, friendly, technical and related to some sorely needed feature or bugfix. I constantly felt unwelcome, like I was trespassing on someone’s lawn. I didn’t want to base my work on that. Eventually I just shrugged and left.

Totally fair! I'm sorry to hear you had that experience, although I hope maybe you'll someday consider giving it another chance in the future. :)

My personal experience has been different, but I upvoted this because I really appreciated that you shared your own experience without overgeneralizing it.

I'm a fan of Elm, and I'm using it in production, but I think this is very much a case of using some flaws in the way people see Elm to ignore some correct criticism of it.

I've tried to push for fixing the use of CSS Custom Properties in Elm a couple of times (https://discourse.elm-lang.org/t/css-custom-properties/5554) and it really felt like talking to a wall.

The community absolutely suffers whenever anyone comes across one of these issues where there just isn't a solution, and more than that, no communication at all. It implies the project is dead.

I accept that Elm is functionally just stalled and won't see any changes until some arbitrary point in the future, I can live with that. I don't think the project communicates it's state and direction well though, and that leads people to disappointment and the posts you see.

That's a good point and maybe I shouldn't have re-posted these stories in my comment as I have not personally witnessed this behavior. I just know that when I started learning Elm initially (Nice Frontend master courses btw) I ran into this sentiment a good bit on reddit and hackernews so thought there was probably something to it if it was being echoed by so many.

I'll add a reply to my comment to make it clear this is hearsay and doesn't necessarily reflect the truth.

Thank you, that's very considerate of you!

The way the language is developed drives me nuts. If someone took the effort to fork Elm I would use it in a heartbeat.

Reply on news.ycombinator.com