Live data from Hacker News

Why I’m Leaving Elm

lukeplant.me.uk

101–110 of 450 posts

Re: Why I’m Leaving Elm

#101
post #17

The last time I looked at Elm was about ~4 years and this attitude was already showing. We hesitated building our business front-end in Elm at the time and had a general bad feeling about its future considering the various interactions we had seen. Seeing this article makes me pretty glad I didn't invest time in Elm.

Same. We founded on Haskell but had some need to more front-end oriented code. Can say Elm was never considered because I was hearing this weird stuff back in 2016--not to mention it would just make hiring even harder. Can't trust tooling that will be capricious.

What did you settle on, considering you were otherwise Haskell focused?

Re: Why I’m Leaving Elm

#102
post #34

Earlier quoted context omitted.

Your suggestion for the problems with this project is "Why don't you just fork it and maintain your own?"

That's what forking entails. It's a bit like Brexit. You don't get to stay in the club. If there are sufficient people unhappy with Elm but are cohesive enough to push the compiler forward, then why not?

You dont even have to push anything forward. Example Redhat's compilation of code or "forked" by CentOS, who were providing just a little more freedom. We all know how that ended.

Just keep in sync with the main project, and keep the annoying/proprietary stuff out.

> You don't get to stay in the club.

Or you become the club. I think LibreOffice has more club going than Oracle's OOo.

Re: Why I’m Leaving Elm

#103
post #43
post #20

This post resonates with me. I'm not deeply involved in Elm, I just have an Elm side project (started on 0.17) with roughly 1k lines of code. Do I love Elm? Yes, definitely. It's such a well-designed language. Lots of thought went into it. It's very focused and has great (albeit sometimes non-obvious) solutions for almost everything. However, the leadership style is also what keeps me from recommending Elm to anyone…

This kind of leadership gave us Go. It's not necessarily bad. If everyone gets their way with the language specs, then all languages will look like a weird dialect of C++ :)

You'll find examples on both sides. Rust is a great example of a successful language growing in the open.

Re: Why I’m Leaving Elm

#104

Earlier quoted context omitted.

That's right[1]; and the author of "Why I'm leaving Elm" understands this, yet claims that it's not possible somehow because the Elm people are hostile to it, and that's one of the reasons the project supposedly isn't really "open source". Something seems a bit off in the reasoning. The only reason you can't fork something is that either you don't have all the code, or there is a license problem. One way not to have…

He doesn't claim it's not possible, he claims that the Elm community will excommunicate you for forking. I can't think of a language or platform that doesn't have some degree of "soft" forking that maintains communion with the language community. It's common for proprietary reasons (linux kernel, anyone?) as well as experimental reasons (e.g. PyPy). So this is an eyebrow raising claim.

On the face of it, my impression is that excommunication, if it happens, is more likely to be caused by the author being burdensome to deal with, than code forking per se.

Of course the author is unlikely to present it that way.

And although I felt the author was moralising in this critique, it may be they are not particularly rude the rest of the time. But even writing a plethora of well-reasoned but difficult to handle posts about what's wrong with your project can be too much.

Well-established languages, platforms and projects such as Linux that have a large labour pool with socially-established patterns of working don't have the same problem, because there's enough labour to deal with it.

Smaller projects just have to turn people away when they become hard work beyond the capacity of the project's core maintainers to handle it, though.

The solution found via FLOSS is to license software so that forking is always possible when a project cannot sustain different visions for the project's direction. This diffuses the tension when people have incompatible needs from the project. Sometimes it comes with drama, particularly if people are competing for attention and trying to persuade others to follow them, but that seems inevitable because of the competition.

It is still understood that forking is permitted and intended to be part of the solution, and the social niceties are that you may be encouraged, perhaps strongly, to go away and run your own fork yourself with your own resources, under a new name/domain/etc. while acknowleging where it came from. Then it's your own job to build a reputation too; it's only fair.

It's very difficult to keep running a project while your competition lingers on the same mailing list, constantly funnelling people towards their fork in the hope of making it more popular. That's a very good reason to "excommunicate" some people, or to forbid some topics such as advertising the other project repeatedly.

Re: Why I’m Leaving Elm

#105

Earlier quoted context omitted.

That's right[1]; and the author of "Why I'm leaving Elm" understands this, yet claims that it's not possible somehow because the Elm people are hostile to it, and that's one of the reasons the project supposedly isn't really "open source". Something seems a bit off in the reasoning. The only reason you can't fork something is that either you don't have all the code, or there is a license problem. One way not to have…

He doesn't claim it's not possible, he claims that the Elm community will excommunicate you for forking. I can't think of a language or platform that doesn't have some degree of "soft" forking that maintains communion with the language community. It's common for proprietary reasons (linux kernel, anyone?) as well as experimental reasons (e.g. PyPy). So this is an eyebrow raising claim.

What would they do? I'm not sure there's an actual threat to follow through on. They can't block a forked compiler from, for example, using official packages without close-sourcing their own compiler (to prevent it from bringing in whatever change makes it work again).

At that point, why bother respecting the threat? A forked compiler isn't going to get maintainers? A package depending on the forked compiler isn't going to be maintained? The social cost is possibly something to think about, but if one is set on leaving the community anyways then it's a choice between you choosing to not interact with the community and them (possibly!) choosing to not interact with you.

Re: Why I’m Leaving Elm

#106
post #22

I‘m not sure why this hasn’t been mentioned by anyone: If you’re unhappy with Elm‘s constraints the obvious solution is to switch to PureScript (purescript.org). It’s basically are more powerful Elm like language with a great FFI and absolutely no constraints how to work with JavaScript. There are also a lot of compatibility packages to provide functions and workflows from the Elm ecosystem.

PureScript is wonderful. But it's a very steep learning curve if you don't already know Haskell, and the documentation tends to lag quite a bit behind the language.

Re: Why I’m Leaving Elm

#107
post #98
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…

Indeed. Author seems to confuse open source and open access. Or he may like them to be one and the same thing: though luck.

The terminology is irrelevant. If you have certain expectations from the open source communities (among the diversity of possibilities that are open source) the narrative of what happened (especially with regards to being considered persona non grata if you fork) are worth knowing about.

Re: Why I’m Leaving Elm

#108
post #93

Earlier quoted context omitted.

Except those BDFLs give you escape hatches to do whatever you want. Elm removed it. It's the same as Clojure, if they didn't let you use your own Java libraries. Or if you couldn't write C extensions for Python. Rich Hickey isn't going to chastise you for resorting to a Java library if you have to, because despite Clojure being an opinionated language, at the end of the day he's pragmatic, which is why Java interop i…

Maybe this extreme limitation is necessary in the Elm's author vision. It's open source. You can always fork and implement your own vision. In fact, you're encouraged to do so.

Forking is not the solution to every disagreement.

Re: Why I’m Leaving Elm

#109
post #98
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…

Indeed. Author seems to confuse open source and open access. Or he may like them to be one and the same thing: though luck.

I'm not sure people saying this know that the author is one of the "core developers" of Django. It is safe to assume that his expectation of "open source" is not far-fetched at all.

While you may have a point, language developed with closed process and just the source published in one of the famous code hosting sites need not emphasize on having a "community"[0] if it is not really looking to hear things from the "community".

[0] - https://elm-lang.org/community

Re: Why I’m Leaving Elm

#110

Earlier quoted context omitted.

He doesn't claim it's not possible, he claims that the Elm community will excommunicate you for forking. I can't think of a language or platform that doesn't have some degree of "soft" forking that maintains communion with the language community. It's common for proprietary reasons (linux kernel, anyone?) as well as experimental reasons (e.g. PyPy). So this is an eyebrow raising claim.

What would they do? I'm not sure there's an actual threat to follow through on. They can't block a forked compiler from, for example, using official packages without close-sourcing their own compiler (to prevent it from bringing in whatever change makes it work again). At that point, why bother respecting the threat? A forked compiler isn't going to get maintainers? A package depending on the forked compiler isn't go…

It's still worth knowing that they're being jerks about it, since that falls outside of the social (but obviously not the legal) aspects of open source.
Post reply on HN