Hacker News Reader

Comment by Kaze404 | Hacker News Reader

I also love Elm, but the fact that it is a niche language now doesn't mean it's all it ever will be. There's nothing really stopping anyone from adapting Elm to the server for example, but the reason it hasn't been done yet is because it's best to focus on solving one problem at a time. If Evan just translated the Node standard api 1:1 for example, it wouldn't be Elm or Node and there would be no reason to use it.

View on HN

There's the core team, which is extremely unfriendly to any kind of user-driven development of the language.

The whole reason Elm has been stuck in a niche when it had _huge_ hype around 2015 and everyone was sure it would be the "next big thing" on the front-end is that the developers have tried to keep full control of the language and keep shooting down proposals by users. It's either their way or the highway.

I'm familiar with those controversies, and most if not all of them I would side with the Elm team. The thing is that, yes it is nice to get user-driven development but they seemed to be proposing to bring back concepts from their OO experience and/or baking in features that should not be part of the core library and are easily implemented if you understand how Elm is wired. Seems like these users are excited to contribute but need to get more familiar with FP before contributing to a higher level FP library. I remember one where the proposal could be easily be implemented generically with ports and any other JS library instead of bringing some weird binding logic to A specific JS library. Add the fact that devs from the FP world are concise with their explanations and you have a recipe for miscommunication problems when trying to explain why that idea is DOA to someone not familiar with core FP concepts.

Eh, it isn't just that though. I recently made a big push to try and get a relatively small change through (setting CSS Custom Properties), which is a big blocker for using a lot of web components (which is officially suggested as a way to deal with interop for the language), and will likely block interaction with future web APIs that use custom properties.

I went through and collected up the reasons to do it, distilled it down and gave examples as requested by the core team and got lots of positive feedback from the community, and just got no response from the core devs and nothing happened.

I agree not all changes people propose are good, I like the fact the language is opinionated and doesn't include half-baked ideas, but there is literally no way to get anything through into Elm core, any attempt to do the legwork is just ignored and thrown away. It is a one-man project and that's it, but they pretend that isn't the case.

Honestly, the answer is probably an unstable fork of the language for more experimentation and development, which to be fair, anyone could do¸ but obviously maintaining that would be a lot of work (I don't want to imply that the core Elm team have some responsibility to do it).

That's not really what I'm talking about. For instance, a few years ago when I was really into Elm, I wanted to implement a WebAudio library. Back when Elm was an FRP language, I thought it would be a great fit with the language's model.

I even got a proof of concept working and showed it off in the Elm Slack.

And then I got told my library would not get accepted on the official package repository because the core team was developing their own "correct" abstractions for the main Web APIs and they did not want third-party libraries to compete with the core team's libraries, as regular web developers don't know what they're doing and are incapable of choosing the "right" abstractions, which apparently only the Elm core team is capable of doing.

That experience turned me off Elm for good.

Flash forward to 2020: There is still no "official" Web Audio library. (There are a few non-official ones on Elm Packages)

It's your right to side with the core team, but they're the ones pretty much killing the language's chance to see any real usage.

Yea it's too bad. If the core team was more open and/or communicative I'd use Elm for production. Maybe you've already seen this but there is a pretty solid blog post detailing the state of Elm: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/

Is there any reason why a group of users didn't fork the language? Lack of coordination?

From what I've seen in HN people are more interested in complaining about how Evan handles the language than trying to do something about it or suggest a better approach. Just makes me trust him more, personally.

On my end, it's mostly lack of time.

Reply on news.ycombinator.com