Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I'm leaving Elm (2020)

lukeplant.me.uk

Post reply on HN
Print view View original

41–50 of 89 posts

Re: Why I'm leaving Elm (2020)

#41

Post by wk_end »

jgilias wrote: post #31
fortran77 wrote: post #29

I loved Elm, and it's disappointing it never achieved critical mass. We wrote a few front-ends with it about 6 years ago. Very easy to write, debug, and deploy

Me too. It’s one of the big “could’ve been” in my opinion. Though I’m convinced it didn’t reach critical mass purely because of community management issues mentioned in the post. Too many people just threw their hands in the air and divested from Elm because of it. Not everybody wrote a blog post about it.

While those community management issues probably didn't help, I don't think Elm's failure to break out can be placed purely on their shoulders.

The big reason why it - and all the other typed/functional compile to JS languages (PureScript, Reason, etc.) - remained niche is because TypeScript came along. It integrated with the ecosystem more seamlessly, was instantly comfortable for JS devs, and was backed by MS who gave it first-class support in VSCode. Arguably TypeScript is not as good as those other languages, but none of them are better enough to overcome those network effects.

Re: Why I'm leaving Elm (2020)

#42

Post by IshKebab »

lolinder wrote: post #20
catgary wrote: post #15

Earlier quoted context omitted.

I kind of wish the effort spent on Roc was put into productionizing/commercializing Koka (which Roc draws a lot of inspiration from) rather than starting an entirely new language. Like I get starting from scratch when it comes to Haskell, since there’s so much baggage there, but Koka is a pretty blank slate.

Koka is still pretty much one person's project [0], and it's not for lack of PRs [1]. To push Koka forward at the kind of pace that Richard wants to move would require forking it or commandeering it, and it makes total sense that neither option is as appealing as just starting fresh. [0] https://github.com/koka-lang/koka/graphs/contributors [1] https://github.com/koka-lang/koka/graphs/contributors

I think your second link meant to go to the open PRs... but anyway there are only 30 open PRs? That seems relatively low?

Re: Why I'm leaving Elm (2020)

#43

Post by hombre_fatal »

maxiepoo wrote: post #18
hombre_fatal wrote: post #14

I think this post captures the wave of entitlement among a group of Elm participants of that era that led to what looks like catastrophic burnout in evancz, Elm's creator. It's been a while since I watched them, and I recommend his talks, but at least one or two of his talks are centered around what is basically unfair expectations. In one talk, [bad paraphrasing, but] he compares how people's expectations of him and…

Basically, Evan decided he wanted Elm to be a pre-packaged closed ecosystem where it was easy to develop very simple standalone apps, but made it very difficult to impossible to actually integrate with any existing JavaScript code or libraries. This was a baffling decision to people who thought Elm was supposed to be a practical language. Blaming everything on "entitlement" from people who bought Elm's marketing abou…

The entitlement doesn't come from thinking "dang, the project doesn't do what I want".

It comes from getting worked up that it doesn't. And it comes from getting worked up that your github/forum/slack correspondence doesn't go in your favor just because you really want something, even if you think you should have more clout because it's a small community.

Elm made a controversial but reasonable trade-off for its packaging ecosystem: No synchronous FFI, only async FFI (over ports or web components). That means that you can count on Elm packages to not have runtime bugs due to sync JS which is a reasonable guarantee with reasonable workarounds.

As for whether Elm is impractical or impossible to integrate with JS code because of it, did you try? To me this complaint is like when I used to read people saying JS Promises led to worse code than JS callbacks early on in Javascript's transition. I couldn't relate to it much. You learn the idiosyncrasies and you move on.

I think part of the entitlement is the people who choose to never move on. Elm sucks, it's impossible to integrate, it's impractical, nobody should use it. Or... exit the theater and let the rest of us enjoy the show?

Re: Why I'm leaving Elm (2020)

#44

Post by fmbb »

Tangentially, does anyone know how to actually get anything done with rescript?

I feel like I would love it. It seems pretty darn awesome.

But getting started on a MacBook Air 2018 seems like an exercise in defeat. Building the toolchain takes ages, I have tried twice just getting started and never got to compiling any examples.

Is anyone using rescript for anything?

Re: Why I'm leaving Elm (2020)

#45

Post by chongli »

josephcsible wrote: post #5

tl;dr: the Elm compiler has a hardcoded whitelist of projects allowed to use certain critical language features, and anyone who releases a fork of the compiler without that antifeature gets banned from the project's community.

So why hasn't anyone set up their own hard-fork community a la neovim? Just not enough interest in it?

Re: Why I'm leaving Elm (2020)

#46

Post by hombre_fatal »

santoshalper wrote: post #40
msm_ wrote: post #26

Earlier quoted context omitted.

Author addresses this at the beginning, but I disagree with them: >This means that even if a single person wrote every line of code of a language's compiler themselves, when it comes to thinking about the project, they need to think of themselves as stewards and not owners I respect the author if they believe this and stick to it (they are involved in OS too), but for the rest of us this is a sure way to burn out.

If you don't want to be a steward of an open technology, why on earth would you become an open-source maintainer?

Almost nobody knows what it's like to maintain a popular project until they do it.

It's very hard to not spend all of your time managing people.

We like think that even responding to issues and pull requests are "just code", but they are actually people problems. You're managing people.

For example, this person spent a week on this pull request, but it wasn't something you wanted to be done, and they didn't do it the way that it should have been done. What do you tell them and how do you tell them? Now let's say they are a vocal person in your tiny ecosystem. It's not easy.

And a lot of the ecosystem you get is pure luck of the draw. Since ecosystems self-select (people who don't fit in in certain ways move on) you can get dynamics that really have nothing to do with you, whether you had zero presence or were 100% prescriptive about how the ecosystem should work. It's kind a bizarre to see over time. (Message boards back in the day were a good example of this too)

Re: Why I'm leaving Elm (2020)

#47

Post by giraffe_lady »

fmbb wrote: post #44

Tangentially, does anyone know how to actually get anything done with rescript? I feel like I would love it. It seems pretty darn awesome. But getting started on a MacBook Air 2018 seems like an exercise in defeat. Building the toolchain takes ages, I have tried twice just getting started and never got to compiling any examples. Is anyone using rescript for anything?

I have used rescript quite a lot but never really ran into problems like that with the tooling. The tooling is pretty twiddly so I'm not surprised. But for me more in how it integrates with "normal" frontend tools. It's easy to wire it up in a way where the compiler doesn't always get all of your most recent changes, or the compiled artifacts aren't picked up by the js bundler correctly.

Anyway I have since switched to gleam, mostly for project governance and tooling reasons! The particular way rescript ended up eventually emerging from the reason/bucklescript schism I think just had it shed a lot of interest and goodwill. The core of the language is so so strong (because of ocaml) but they seem almost embarrassed by the ocaml connection and seem to be trying to distance themselves from it. They've implemented a new standard library that reproduces mutable JS semantics and I just think that's a big step back too.

Gleam is a HN darling that comes up all the time but it's in a really great spot for being such a young language. Very very similar semantics to rescript if you're targeting JS, rock solid standard lib, tooling is very good, package ecosystem surprisingly robust and high quality. It's not always obvious if a library supports js targets or erlang or both, and I hope they address that soon. I think they have a much clearer idea of what they want to accomplish than rescript does so I switched. IDK check it out, I originally ended up in rescript looking for an elm replacement and now I've ended up here.

Re: Why I'm leaving Elm (2020)

#48

Post by gregors »

alphazard wrote: post #32

The author is critical primarily of Elm's governance and processes, and claims that these are what killed the project. I don't think that's entirely true. There was a recent interview with the creator of Elm here. https://www.youtube.com/watch?v=0SUM4869ODc I'd encourage everyone to watch that as a grain of salt to TFA. It seems like the project leader felt he was being taken advantage of, and was just not getting ou…

>>>> That's his decision to make and he doesn't owe anyone anything. If you want continued support, pay up.

Completely correct, and the users of Elm also don't owe him anything. They are free to hold their opinions and free to move away from Elm ...and they did.

In the end Elm will be remembered for being an extremely interesting technology but mainly failed in industry due to poor project/community relationship.

Sometimes interesting tech just isn't the right fit for business. C'est la vie.

Re: Why I'm leaving Elm (2020)

#49

Post by hombre_fatal »

chongli wrote: post #45
josephcsible wrote: post #5

tl;dr: the Elm compiler has a hardcoded whitelist of projects allowed to use certain critical language features, and anyone who releases a fork of the compiler without that antifeature gets banned from the project's community.

So why hasn't anyone set up their own hard-fork community a la neovim? Just not enough interest in it?

1. In open source, everyone plays lip service to how you can just fork things, but nobody wants to do the hard, infinite work of building a new ecosystem. You'll just rediscover the exact thing that burned evancz out.

2. Elm's stance on sync vs async ffi isn't a big deal. A fork is like when there was that IcedCoffeeScript spin off on CoffeeScript: https://maxtaco.github.io/coffee-script/ -- it's more of a gimmick in what is already a tiny ecosystem.

3. Last I checked there was "elm-janitor" for managing patches and getting them into core Elm as an end user or something. Dunno what came of it, but I think it goes back to only a handful of people are going to use something like that. And there are already Elm-inspired languages with ~0 users out there. The hard part is ecosystem.

It's not like Javascript where you can launch something like preact (react but smaller) and get 38k github stars. It's not going to be rewarding.

Re: Why I'm leaving Elm (2020)

#50

Post by FullGarden_S »

santoshalper wrote: post #39
FullGarden_S wrote: post #27

Earlier quoted context omitted.

No, its not. They are focused on introducing ELM on the backend as well. ELM isn't backed by big corpos like Rust and Go do so their way of operation will differ by a huge margin than those two langs, especially in terms of marketing so its inaccurate to judge that its dead just due to the inactivity. https://www.youtube.com/watch?v=0SUM4869ODc

Dead means different things to different people, but there is no way in hell I'd start a new project using a niche language that hasn't been updated in almost a year.

I see.

I would though. ELM has a very simple, straight forward syntax and everything revolves around the ELM architecture, which makes the whole thing very intuitive. I believe a statically typed and functional language will do just fine without any update for years as long as the initial implementation is done right. Unless there is a need to add some new feature, there is not point in updating the language if all the essentials were well implemented already. ELM compiles to JS and not to a native architecture. It'd be inappropriate to view ELM like one would view languages like C or any that uses LLVM as its backend.

Post reply on HN