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…
Why I’m Leaving Elm
191–200 of 450 posts
Re: Why I’m Leaving Elm
#192Re: Why I’m Leaving Elm
#193I 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…
Re: Why I’m Leaving Elm
#194I 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…
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
#195I 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…
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
#196These 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'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
#197Elm 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?
Re: Why I’m Leaving Elm
#198For 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...
Re: Why I’m Leaving Elm
#199We 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.
Re: Why I’m Leaving Elm
#200After 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…
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.