Live data from Hacker News

Why I’m Leaving Elm

lukeplant.me.uk

141–150 of 450 posts

Re: Why I’m Leaving Elm

#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 Elm in the past for a hobby project with an eye towards using it in production, I probably won't ever use it. I loved the original promise. Evan's ideas about the Elm Architecture are worth reading and learning for anyone. But, as many others have pointed out, if one has to maintain a project over the years, the breaking changes in the language would have caused great bouts of teeth gnashing.

I don't love Java, but over the years I've come to expect that with each new major version of the language, that a small amount of work needs to be done to guarantee my production code will keep working and I can integrate new features as I have time. With Elm, every release forced me to spent hours figuring out how to make my old code work again.

Re: Why I’m Leaving Elm

#142

Earlier quoted context omitted.

The community is more valuable than the code, because the community writes the code. So being cut off from the community is a major blow to a fork, and substantially increases their work burden.

Your fork isn't a significant amount of work, unless they've really threaded in the must-be-in-Elm-Kernel check throughout the entire compiler. Versus trying to rewrite your dependency in Elm rather than enabling importing JS, enabling JS is likely to be simpler since the functionality already exists to let Kernel modules do it.

This kind of dismissive response is in line with the examples provided in the OP.

Re: Why I’m Leaving Elm

#143
post #59

Earlier quoted context omitted.

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 continued reading and found bunch of more passages where the authors understanding of open source seems to be incorrect. The author is one of the "core team" members of Django[0]. So, it is safe to say that whatever assumptions he has about open source is not a fantasy and cannot be compared line-by-line to a text book definition of open source. [0] - https://lukeplant.me.uk/personal.html

I don't think the author being a member of Django adds any weight to his arguments.

Re: Why I’m Leaving Elm

#144
post #80

For me, the best thing I got from this critique was the link to this 2018 talk by Evan: The Hard Parts of Open Source, https://www.youtube.com/watch?v=o_4EX4dPppA I found Evan's talking style really entertaining and enjoyable, and I totally relate to the first part about "why don't you just..." and "have you thought about delegation..."! The HN comments here are near uniformly negative towards Elm and supportive of L…

The article's criticism about the 0.18 to 0.19 issues is spot-on, but I agree with you that the author comes off as feeling entitled.

The reason why Elm is fun to work with is that it's Evan sharing his hobby project with you. And that's it. There is no support, no long-term maintenance, no implied warranty, nothing. Still, it works for me :) and it is Open Source in the way that I can fix bugs myself, if I have to.

One of the reasons why I chose to not do open source myself is because of people like the author here. You give someone free source code for a useful tool and they'll come back and ask for you to fix their issues.

For example, I once patched a Heroku buildpack because I needed it to work. Due to how GitHub works, my fork was public. A while later, Heroku linked to it. And then I started getting a lot of messages from whiny entitled pricks. Apparently, they thought that it would be my duty to provide support to them. For free, of course, because it's open source...

I'm pretty sure Evan had a similar experience and that's why Elm comes with no support, no warranty, and no way for you to influence it.

Re: Why I’m Leaving Elm

#145
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" incessantly in their writing, it's like some weird cult. You'll notice it from the quotes of Evan and Richard in this article.

The forbidden JavaScript FFI is called either "kernel modules" or "native code" despite it being neither. They also claim it's an "implementation detail" or "flaw" despite the fact that it's obviously not.

There are more examples. If you go against any of these rules then you're ostracized.

I quit using Elm because of this problem above all else. I recognize the need to have respectful rules for conversation but having a dialect of newspeak that you're forced to use is just too ridiculous.

Re: Why I’m Leaving Elm

#146
post #80

For me, the best thing I got from this critique was the link to this 2018 talk by Evan: The Hard Parts of Open Source, https://www.youtube.com/watch?v=o_4EX4dPppA I found Evan's talking style really entertaining and enjoyable, and I totally relate to the first part about "why don't you just..." and "have you thought about delegation..."! The HN comments here are near uniformly negative towards Elm and supportive of L…

Great talk indeed.

I feel like it might be helpful to online communities to add a real "intent" field to their posting forms, like here in this video: https://youtu.be/o_4EX4dPppA?t=2489

Re: Why I’m Leaving Elm

#147

Earlier quoted context omitted.

It doesn't really solve the problem. How do you format this code with tabs: function name(arg1, arg2, arg3 The other issue is with maximum line length. If you have a maximum line length of 80, do tabs count as 2 spaces, 4 spaces, or 8 spaces towards meeting that line length? Using spaces ensures that it at least looks consistent, independent of your tabstop settings.

> It doesn't really solve the problem. How do you format this code with tabs: function name(arg1, arg2, arg3 Just wondering… do you realign the parameters every time you rename a function?

I don't actually personally do this kind of alignment, but it was the easiest example for me to come up with to illustrate the problem of needing to align text on different lines.

Re: Why I’m Leaving Elm

#148

Earlier quoted context omitted.

Yep! If people used tabs, then everyone can display it how they like and these stupid discussions wouldn’t be necessary. Alas, for some reason the world has rallied behind spaces. Sigh.

It doesn't really solve the problem. How do you format this code with tabs: function name(arg1, arg2, arg3 The other issue is with maximum line length. If you have a maximum line length of 80, do tabs count as 2 spaces, 4 spaces, or 8 spaces towards meeting that line length? Using spaces ensures that it at least looks consistent, independent of your tabstop settings.

In elm you'd do one of two things: keep all the arguments on one line, or put each on its own line. At least, according to the formatter's opinion (which is honestly so nice to use when it just snaps everything into place every time you hit cmd-s). Of course, this convention is violated all the time when listing all the public exports of a package (with good reason IMHO; it lets your group similar things onto lines together) so it's not much of a convention: https://github.com/rundis/elm-bootstrap/commit/e412efe628854...

Re: Why I’m Leaving Elm

#149

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…

gawk and bash aren't UX generating tools

quoting: "And a further consequence of this is that non-English developers and end users are discriminated against, due to the difficulty of formatting numbers and dates in correct ways for non-English locales."

The issue seems to be hypocrisy of the Core team and not that it isn't true open source. Forking a language is suitable only for extraordinarily situations, Elm language might be good but ultimately it's not that extraordinarily good.

Re: Why I’m Leaving Elm

#150

I believe Elm took some major missteps. Despite doing so many things right with the initial designs (and still one of the best designed front-end experiences) it never grew much beyond the early adopters and it basically remained a fun hobby language. I criticized the basic lack of communication and the infrequent updates in r/elm (I believed these infrequent updates were going to kill the momentum of Elm). I was con…

I also eventually came to the conclusion that elm Will be forever niche and can’t become a mainstream language.

I agree with so much of what Evan says in principle, but every time the project development style is criticized, someone pastes a link of Evan basically telling everyone to sit down, shut up, and wait. Which is Evan’s right, but rhetorically speaking, this is horrible. Just a little charm can go such a long way.

Post reply on HN