4 ms·

I think of Elm more as an incredibly influential research language these days. It's very focused, there's no public roadmap or official support and the leaders

by bbkane 3mo ago

I think of Elm more as an incredibly influential research language these days. It's very focused, there's no public roadmap or official support and the leadership (which is far as I can tell is just Evan) is uninterested in most (any?) community building or core team building. But MAN is it nice to work in. This has resulted in several forks/spin-offs. At the recent Gleam conference, Louis Pilfold joked that every Elm user maintains their own compiler :). There are at least 6 of them (two more got announced in the last month, even as the community keeps shrinking). So I'm glad Evan is now working towards 1.0. Maybe folks can call Elm "finished" and one of the successors can do the hard work of unifying some of the forks and growing the community. Personally, the next time I'm looking for an Elm-like thing, I'm going to check out Gleam + Lustre. Seems to have a nice mix of maintainers that care about community and design. And it works on frontend + backend!

brokencode 3mo ago
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.
- Aurornis 3mo ago
  > 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.
  - adastra22 3mo ago
    What feature is that?
    - arthurbrown 3mo ago
      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 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 https://elm-lang.org/news/farewell-to-frp
    - wavemode 3mo ago
      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.
    - crote 3mo ago
      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 https://github.com/elm-lang/websocket
ethagnawl 3mo ago
For whatever it's worth, I've found Gren to be a very capable successor with an active and helpful community.
- desireco42 3mo ago
  Never heard of it and I am glad you mentioned it, thanks. Already homepage and examples look familiar and welcoming.
  - 1-more 3mo ago
    If you'd like an incomplete list of everything that's downstream from Elm, I made one the last time a TEA library got to the front page here: https://news.ycombinator.com/item?id=47678424 https://news.ycombinator.com/item?id=47678424 The creator of Derw shows up one comment later to remind me of one that I was forgetting.
goosejuice 3mo ago
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!
gdcbe 3mo ago
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.
- epolanski 3mo ago
  Elm feels like a simplified Haskell which can handle a single space problem.
- deleted 3mo ago
  [deleted]
- int_19h 3mo ago
  These days, though, why not just use Haskell itself? Upstream ghc cancompile to wasm for several major releases now and there are several actively developed web frameworks, some of them very Elm-inspired, e.g. https://haskell-miso.org https://haskell-miso.org
epolanski 3mo ago
I'm one of those. I extended the language to support a bunch of niceties (essentially supporting a proper error channel and dependency injection through erasable sum types). Elm is a nice language, but Ewan has no interest in building anything truly useful and the whole administration of the language is s disaster.
- rofrol 3mo ago
  Can you share your git repo link?
davidgtonge 3mo ago
I agree and I think the ideas in Elm are applicable in many other contexts. Adopting a new language is just hard, especially with larger teams. I ended up taking some of the ideas of Elm but implementing with Rust and TS - https://dave.tonge.org/articles/make-ts-boring/ https://dave.tonge.org/articles/make-ts-boring/ The basic idea - all application state and view model creation is in Rust (compiled to Wasm). I'm using Rust not really for performance, but for its strong type system. Components are in TS but have a strict contract they can only accept plain input props and output events. Rust processes the events and ships a view model patch to TS. This is not "Elm in Rust/TS" but it is definitely Elm inspired.

by bbkane 3mo ago

brokencode 3mo ago

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.

Aurornis 3mo ago
> 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.
- adastra22 3mo ago
  What feature is that?
  - arthurbrown 3mo ago
    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 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 https://elm-lang.org/news/farewell-to-frp
  - wavemode 3mo ago
    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.
  - crote 3mo ago
    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 https://github.com/elm-lang/websocket

ethagnawl 3mo ago

For whatever it's worth, I've found Gren to be a very capable successor with an active and helpful community.

desireco42 3mo ago
Never heard of it and I am glad you mentioned it, thanks. Already homepage and examples look familiar and welcoming.
- 1-more 3mo ago
  If you'd like an incomplete list of everything that's downstream from Elm, I made one the last time a TEA library got to the front page here: https://news.ycombinator.com/item?id=47678424 https://news.ycombinator.com/item?id=47678424 The creator of Derw shows up one comment later to remind me of one that I was forgetting.

goosejuice 3mo ago

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!

gdcbe 3mo ago

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.

epolanski 3mo ago
Elm feels like a simplified Haskell which can handle a single space problem.
deleted 3mo ago
[deleted]
int_19h 3mo ago
These days, though, why not just use Haskell itself? Upstream ghc cancompile to wasm for several major releases now and there are several actively developed web frameworks, some of them very Elm-inspired, e.g. https://haskell-miso.org https://haskell-miso.org

epolanski 3mo ago

I'm one of those. I extended the language to support a bunch of niceties (essentially supporting a proper error channel and dependency injection through erasable sum types). Elm is a nice language, but Ewan has no interest in building anything truly useful and the whole administration of the language is s disaster.

rofrol 3mo ago
Can you share your git repo link?

davidgtonge 3mo ago

I agree and I think the ideas in Elm are applicable in many other contexts. Adopting a new language is just hard, especially with larger teams. I ended up taking some of the ideas of Elm but implementing with Rust and TS - https://dave.tonge.org/articles/make-ts-boring/ https://dave.tonge.org/articles/make-ts-boring/ The basic idea - all application state and view model creation is in Rust (compiled to Wasm). I'm using Rust not really for performance, but for its strong type system. Components are in TS but have a strict contract they can only accept plain input props and output events. Rust processes the events and ships a view model patch to TS. This is not "Elm in Rust/TS" but it is definitely Elm inspired.