Live data from Hacker News

Why I’m Leaving Elm

lukeplant.me.uk

191–200 of 450 posts

Re: Why I’m Leaving Elm

#191

These posts (and HN comments) really make me wonder if adopters of fringe languages are always going to be thin-skinned developers who get emotional when they realize they won't be part of the language's design decisions. That "On Whose Authority" rant about Clojure complains about the exact same things. And I'll refer to Rich Hickey's response: https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au... . Elm in…

I think its a bit different with a language though. Because so much of other people's work is based on it, removing a feature that was being used causes all sorts of downstream chaos. Every time a language release breaks backwards compatibility it tends to really upset people, I think maintainers always need to be cognizent that their choices effect others.

Re: Why I’m Leaving Elm

#192
Maybe am mistaken but isn't a language that hasn't reached version 1 by its nature supposed to have breaking changes. It is expected that while you can use the language for your projects there is no guarantee that new additions won't break your code so you use it at your own risk unless Elm uses a different versioning system.

Re: Why I’m Leaving Elm

#193

I fully agree with everything listed in this article. One point he alluded to (by mentioning the "friendly" exclamation marks) but didn't fully address is the Elm community's bizarre and infuriating language policing. You can't say the word "guys" in the Slack channel, or a bot will come and correct you, and tell you to say "folks" instead. And from then on, you'll notice the core team all use the word "folks" incess…

> You can't say the word "guys" in the Slack channel, or a bot will come and correct you, and tell you to say "folks" instead. Being asked to use inclusive language is a weird thing to complain about, especially as the very first example you give. > And from then on, you'll notice the core team all use the word "folks" incessantly in their writing, it's like some weird cult. I use "folks" and other non-gendered langu…

Perhaps it feels a little odd when one form of respect, addressing people properly, is strictly enforced when in a much broader sense, e.g. by not acknowledging (potential) contributors, it's so obviously lacking. Imagine holding a door with one hand while giving the finger with the other. What good is that?

Re: Why I’m Leaving Elm

#194

I fully agree with everything listed in this article. One point he alluded to (by mentioning the "friendly" exclamation marks) but didn't fully address is the Elm community's bizarre and infuriating language policing. You can't say the word "guys" in the Slack channel, or a bot will come and correct you, and tell you to say "folks" instead. And from then on, you'll notice the core team all use the word "folks" incess…

> You can't say the word "guys" in the Slack channel, or a bot will come and correct you, and tell you to say "folks" instead. Being asked to use inclusive language is a weird thing to complain about, especially as the very first example you give. > And from then on, you'll notice the core team all use the word "folks" incessantly in their writing, it's like some weird cult. I use "folks" and other non-gendered langu…

I think it depends about messaging.

There's one aspect to saying "Hey, we are trying to be ultra-inclusive, and there have been members in this group that feel offended or excluded via the term "guys". To make everyone feel welcome, we ask you refrain from "guys" and use the more inclusive "folks", instead.".

vs

"'Guys' is a non-inclusive and harmful term. Please consider using 'folks' instead."

I don't know how the Elm slack channel has broadcasted this messaging, but the first offers the benefit of the doubt and a chance to understand the situation / learn. The second is just asking to put people on the defensive.

Unfortunately, I've come across the second type of messaging far too often, and it often just induces eye-rolls more than anything.

Re: Why I’m Leaving Elm

#195
post #59

I don't agree with everything here. Open source really does mean that you just have all the code to rebuild the thing from scratch under the right sort of license. Open source doesn't mean anything else, like having access to design decisions. Interaction style and personalities are also not part of the definition of open source; open source doesn't mean nobody is brusque or abrasive. Some communities have additional…

Agree. I'm gonna be honest and say I haven't finished the entire article so author might have elaborated further after, but I got a chill when reading the following passage: > The second is that if you advertise something as Open Source, there is a common set of assumptions about what that means, some of which are explicit in accepted definitions of the term. It seems the "common set of assumptions" is around that pe…

I find you're being needlessly formalistic here. The author is explaining where they are coming from. What their understanding and expectations in the open-source world are. This helps to understand their position. That initial part was intended (I guess) to make comments like yours redundant. Because that way we can understand what the author means without guessing about their usage of the term.

The article does not require you to share that definition. And haggling over the precise definition of open source does not change their argument one bit. You can say that you use a more restricted definition, and that is it.

Re: Why I’m Leaving Elm

#196

These posts (and HN comments) really make me wonder if adopters of fringe languages are always going to be thin-skinned developers who get emotional when they realize they won't be part of the language's design decisions. That "On Whose Authority" rant about Clojure complains about the exact same things. And I'll refer to Rich Hickey's response: https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au... . Elm in…

> most people would agree that user packages shouldn't be able to invent yet more custom operators

I'm actually curious why; I have yet to see people actually abuse operators outside of C++, and those were in the standard library

Re: Why I’m Leaving Elm

#197

Elm wasn't the right language/community for this author and that's ok, not everything is for everyone. I use and love elm as something to write my side projects in. It has a zen like appeal for many reasons: - No runtime exceptions in practice, so you are developing against the compiler and almost never need to manually test what you're writing - Very opinionated about how to do most things. There's usually just one…

May I ask, how are you doing i10n?

I haven't had to yet, my side projects are mostly just for me and my friends.

Re: Why I’m Leaving Elm

#198
I've used Elm professionally for about a year, having done full rewrites of both a bloated React/Redux SPA and a map data visualizer with complex JS interop using ports to Leaflet, AWS Cognito, etc. Luke Plant's blog post doesn't at all reflect my experiences with Elm or my feelings about the core team.

For those not privy to the Elm tea, a brief primer: this blog post is primarily concerning a months-old issue regarding the removal of the ability to use native modules, which are effectively patches to the Elm runtime[1] which circumvent the core features of the language that provide its greatest strengths: a genuinely helpful compiler and ironclad runtime guarantees (still have yet to encounter a production runtime error that wasn't on the JavaScript side of things!) This "feature" (used loosely) was largely undocumented, always verboten from distribution in user packages, and never intended as anything more than a stopgap measure in extremely rare cases.[2] It was /officially/ not a core language feature intended for widespread usage, and consistently advised against by the Elm team. The removal of native modules was spoken about publicly months before the breaking upgrade. It came as no surprise to me. As an engineer who tries really hard to be responsible, I do not build software which relies on features which are advertised as 'do not use unless absolutely necessary' and are soon-to-be deprecated unless I'm willing to accept the inherent risk of doing so.

The core Elm team was, in my opinion, extremely communicative, well-reasoned, and thoughtful in this change and in others, despite the inconvenience to a small subset of people. For each feature discussed in Luke's post, there is an accompanying Discourse thread[3], discussion on Google groups, Github gists[4], etc., that carefully lays out the reasoning, and carefully consider the scope of a change (in the instance of the removal of custom operators, the Elm team analyzed the package ecosystem and determined less than 5% of packages were affected)[4].

I won't cover the moral arguments around the obligations of open source maintainers as this has been covered ad nauseam with the Clojure and Rust fiascos of a similar sort - though I personally believe maintainers don't owe anyone anything, and I try to treat all free software graciously, as a precious gift, lucky to receive it at all. I will say that Elm's somewhat slow, closed BDFL-ish governance is well-documented as well[5, 6], available to all who seek to understand the Elm development process and decide for themselves if this is an ecosystem to hitch their wagon to. Of course the Elm maintainers get to patch their own runtime with native modules, because they are implementing core parts of the language, it's practically tautological. That users living in userland cannot do it is not unfair; it's a language design feature. What Luke seems to see as a stifling of an open community by the closure of issues and deletion of posts on the Discourse is often basic organizational maintenance to handle redundancies. Conversations around these issues have happened for months and in some cases years, and decisions have been made. They may not be to everyone's tastes. That should be just fine! If someone went to Famous Amos Cookies on Discourse, Slack, their mailing list, and opened a Github issue and PR suggesting this genius idea they just had, it's so good, wait for it - an oatmeal cookie without raisins! - I hope they would clean it up, close the issue, delete my posts, etc., for their own sanity. Not to mention that the opening to Luke's opus here is an admission of his own rudeness to the Elm team on most of these fora. Of course the relationship with maintainers will be strained with this kind of behavior.

There are critiques of Elm, to be sure. The pace of releases is somewhat slow, custom operators might be nice for 3rd party parsing libraries, it might be cool to have a PR merged in to get that fuzzy feeling only OSS contributors get. But you cannot reasonably argue that Elm's team has been unfair, discriminatory, uncommunicative, or arrogant (pathos, so much pathos here!). I don't generally post comments anywhere, but articles like this are irresponsible and damaging not just to the well-being of maintainers who are being generous with their time trying to make something with great care, but to people (like many top level commenters here) who might have tried Elm but won't due to an inside baseball post from a spurned developer. It makes me actually sad, like want-to-cry sad.

[1] https://newfivefour.com/elm-lang-basic-native-module.html (any somewhat experienced Elm developer will get nervous looking at this trivial example and immediately see what might break)

[2] https://groups.google.com/forum/#!msg/elm-dev/1JW6wknkDIo/H9... (2015!)

[3] https://discourse.elm-lang.org/t/native-code-in-0-19/826

[4] https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc7...

[5] https://www.youtube.com/watch?v=o_4EX4dPppA

[6] https://github.com/elm/projects/blob/master/roadmap.md

Re: Why I’m Leaving Elm

#199
post #10

We had a pretty similar experience with elm around cookies. The elm-lang/cookie repo README starts with "Cookies are an ancient mistake of web browsers. They make a bunch of security problems quite easy, so consider this an expert library." However, they never address reading cookies, so if you're using a framework that does CSRF protection with cookies, you have to use ports, which adds quite a bit of complexity for…

Well, you should be using `httpOnly` cookies (i.e. unusable from the browser) and setting them from the server. Your browser client will automatically send them. document.cookie is a security vulnerability that's hard to find in any respectable documentation. It's up there with sql string concatenation.

SQL string concatenation is fine. You mean parameter concatenation (into the query string).

Re: Why I’m Leaving Elm

#200
post #141

After reading a large number of the responses here, I feel like I've noticed a pattern - two types of comments: 1) I've used the language and agree with the conclusions of the post even if I don't necessarily agree with every point. 2) I haven't used the language, but I believe open source projects must be maintained by their maintainers as they see fit. I actually agree with both of these positions, but, having used…

I'm not much into web development professionally, but it's something I learn and use a bit as both a hobby and for personal projects. I looked at Elm a while back (maybe two years ago, but I'm not sure exactly). I decided against it after I ran into some issues related to language instability and old documentation. I dug a little further and it appeared to be how the Elm project was run, so I stayed away.

On your second point

> I haven't used the language, but I believe open source projects must be maintained by their maintainers as they see fit.

I totally agree. But I also think it's good when others point out the weaknesses in the project publicly, to prevent people from wasting time or having to deal with certain personalities. As long as it's true and done in a professional manner, an important part of open source is harsh public criticism.

Post reply on HN