If it's really just a "hardcoded whitelist" that causes trouble, said fork would truly be easy to maintain.

Until they do some other halfbaked thing that's harder to follow along with. When people show you who they are, believe them the first time.

Compilers are supposed to be boring, especially when your language has ~exactly 1. If you can't trust the people maintaining it, it's too much risk to take. Having to do an entire rewrite in a different language can easily kill a company or a project.

Would you need to maintain a fork at all? Couldn't you obliterate the rule when building the compiler?

What's the difference between that and a fork?

One doesn't require a "community of maintainers", its an adhoc tool you use to get your own stuff done, every project has them what is one more?

Until another change against the community interest comes along. You only trust the "benevolent dictator" for as long as they remain benevolent.

It would be, if the code wasn't so horrifically bitrotted at this point. GHC has changed a lot since Elm last got any meaningful update, and they decided to use unsafe GHC primitives everywhere that have no support guarantee. You have to fix a bunch of issues with the compiler source before it will even compile on a relatively new version of GHC.

It would be weird to create such a fork casually, but it's a bit surprising that nobody in the community did it by now. Isn't forking the open source way of dealing with political disputes like this?

Gren is apparently such a fork: https://gren-lang.org/

Is it? https://gren-lang.org/book/faq.html#what-are-the-differences... doesn't mention anything about native code.

> While we could spend considerable time and effort in creating a language which would look very similar to Elm, we've instead decided to fork the compiler and core packages, and use that as the basis of Gren.

https://gren-lang.org/news/220530_first_release/

One of Evan’s colleagues from NoRedInk actually started his own language heavily inspired by Elm that aims to fix a lot of its ecosystem problems.

https://www.derw-lang.com

I’m not sure if it’ll go anywhere but I like the idea that it’s interoperable with existing JS/TS packages.

I was using Elm full-time back then, and I think some important context to note is that 0.18 had outstanding issues which had seen no movement for years (and PRs were generally ignored). The official guidance was “wait for 0.19.” While 0.19 addressed many or all of these issues, it came with a number of breaking changes, some very significant. It also coincided with a reorganization of the GitHub repos which happened to scrub all past issues, PRs, and discussion as well as a more stringent moderation policy on the official forums.

Well that last bit alone would put me permanently off a language. It's always wild to me when open-source leaders let the power go to their heads. If they want that kind of control over a community, they should go start a backwoods cult. Or at least start a company where they're signing the paychecks.

That's why I left Elm. There were major unfixed bugs for years. I liked the concept, but I couldn't deal with the slow progress to fix things.

> It was bad enough that they got it wrong, but then Evan doubled down by dedicating the opening of his next conference talk to mocking the users who were unhappy about the changes: https://www.youtube.com/watch?v=uGlzRt-FYto

> The part where he mocks a commenter for asking "Is Evan killing Elm's momentum?" is weirdly prescient, given that these events ultimately did mark the slowdown of the Elm community. Elm development came to a near halt about a year later.

Wow, that was hard to watch. He takes people being passionate about Elm and discussing potential issues and mocks them.

If I was a proponent of Elm that felt uneasy about its direction at the time, this would have made it easy to walk away from.