upvote
Yeah Elm has had a very strange arc, but I think calling it a research language is right.

There was a period where it was heavily evangelized. Many blog posts were written and talks given, and there was a lot of enthusiasm and adoption.

Then the author just kind of disappeared and the project stalled.

Which of course he had a right to do since it’s his project, but I think he should have set expectations better from the beginning.

The heavy evangelism helped spread the ideas, but also set up developers to feel blindsided and abandoned.

reply
> Then the author just kind of disappeared and the project stalled.

There was more to the story than that. They made some major breaking changes in v0.19 that broke a lot of apps and left no path for them to continue with Elm, then dug their heels in when the community protested.

If you had an app at your company that used the features they decided not to allow any more, you either had to start deciding which fork to follow or start planning to rewrite your app in something else.

That evangelism turned into an uncomfortable gaslighting where half of the community was trying to tell you that this change was what was best for the language and that you didn’t really need that feature anyway.

There were several forks but I don’t know if any got traction. It felt like an already small community was fracturing into even smaller communities right after alienating a lot of people.

reply
What feature is that?
reply
On top of the already-mentioned JS interop breakage, Elm 0.19 also dropped native Websocket support[0]. The API had issues (fair), so it was dropped rather than improving it due to wanting to do it perfectly (okay, I guess), buuut due to the JS interop restrictions this meant that 3rd-party experiments or alternatives were impossible (??), which meant that any use of Websockets was in practice now completely impossible! If I recall correctly something similar happened to other core libraries.

This "nobody is allowed to do this until Evan himself has made time to come up with a blessed solution" style of development left a lot of people quite disappointed. Elm was marketed quite heavily as the best thing since sliced bread and the future of front-end web development, but in reality it turned out to be just Evan's toy language which you could look at but weren't allowed to touch. Which is of course allowed, but it does rapidly kill any kind of community around it.

[0]: https://github.com/elm-lang/websocket

reply
This really overstates the problem and situation.

Synchronous interop was removed from Elm. That sucks for synchronous stuff and anything too trivial to be worth async interop.

But async interop is still available. Anything networked, like websockets, is a natural fit for async interop. i.e. a Send(Req) | Recv(Res) port.

It's fine to be mad that a "BDFL" decided on a different set of trade-offs than your preference, but that's what happened.

It's also a learning lesson for people who thought that a tiny, pre-v1.0 ecosystem that already had breaking changes would never break again especially in a way they disagree with. I think it's time to just accept the lesson.

reply
Lots of things were disallowed in 0.19, but probably the most disruptive were that custom native modules were disallowed (which basically means that, only certain official packages would now be allowed to directly call native JavaScript), and the package manager was locked down (which means that you can only install packages from the official elm repository, not GitHub or anywhere else).

You can still indirectly call native JavaScript, in a message-passing kind of way (via Ports or custom elements) but these changes were still really disruptive to many codebases.

reply
One form of JavaScript interop. Instead of being able to write bindings directly to native code, you had to pass messages through "ports" instead.

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

Personally, I was sad to see signals and FRP go in 0.17

https://elm-lang.org/news/farewell-to-frp

reply
The nicest thing of Elm is how much it feels like Haskell. Have built some fun things with Elm years ago.

The second nicest thing with Elm is the philosophy of if it compiles it works. And to be honest you can get that same feeling with most of Rust as well. Sadly not as much of a haskell feeling but at least it has a warm shadow of some of its functional ancestors.

reply
For whatever it's worth, I've found Gren to be a very capable successor with an active and helpful community.
reply
I think because it's so nice, that's why people are disappointed in it's stagnation. But the stagnation is partly why it's so nice!
reply