3 ms·

I have found using Elm a real joy, albeit for hobby projects. I do hope pure functional languages become state of the art by 2026.

t1amat 11y ago
Elm has a lot of beauty to it. I would definitely promote anyone interested in learning FRP in web development to look here first. They really nailed the essence of the architecture, and getting some experience with ML-family languages is bonus, as they are likely more approachable than Lisp-family languages for many. I'm really hoping Evan and the community can make this a more viable solution in the coming years. That said, Elm can be difficult to use today. The foreign function interface is not all that great of an experience. There is a lot of friction in just defining, serializing and deserializing JSON objects. You wind up writing a lot of code you wish you didn't have too. Their great time traveling, hot reloading debugger doesn't actually hot reload anymore. And there is no real back end language synergy to speak of at the moment. Many are looking toward Elixir and Phoenix for support instead of more language-similar Haskell options like Yesod and Snap. The competing PureScript, GHCJS, Websharper and FunScript alternatives also complicate the landscape that Elm plays in greatly.
- bbcbasic 11y ago
  I agree I am learning Elm mainly to learn FRP and do some 'haskell with my hands tied behind my back' because I believe you can get a lot done without resorting to the advanced language features of Haskell. So for me it's a kata for learning how to be a better functional programmer. Once I feel I 'get' the FRP model used I may just go and do the same stuff in another language, see how it plays out in Haskell or Purescript. I feel FP will remain a hobby though and the best I can hope for is to convince .NET colleagues to make immutable classes, use code contracts to avoid null problems, and generally try to minimize state and maybe use Rx. Even F# would be too much of a push for most .NET shops. I have a mortgage and fixing bugs caused by ridiculous state and null references in .NET code pays it and then some :-)
  - t1amat 11y ago
    If I may make a recommendation: check out ClojureScript with reagent and re-frame when you feel you've achieved what you set out to in Elm. While Elm nailed the essence of FRP, ClojureScript really nails the experience I was looking for in ways Elm can not. While it doesn't have the gradual typing and fantastic compiler messages, it is also functional and immutable. But to my view it has all around better tooling, very simple FFI (either reference JS already on the page transparently or pull in JS formally via extern definition files similar to TypeScript typings), optional typing via core.typed, sourcemaps with a native debugger, and a node-like full stack synergy through Clojure but with all the power of the JVM. You definitely lose some confidence at run time due to the dynamic typing, but on the whole I think the gains far exceed that. At least for me it's a package that is very hard to beat.

t1amat 11y ago

Elm has a lot of beauty to it. I would definitely promote anyone interested in learning FRP in web development to look here first. They really nailed the essence of the architecture, and getting some experience with ML-family languages is bonus, as they are likely more approachable than Lisp-family languages for many. I'm really hoping Evan and the community can make this a more viable solution in the coming years. That said, Elm can be difficult to use today. The foreign function interface is not all that great of an experience. There is a lot of friction in just defining, serializing and deserializing JSON objects. You wind up writing a lot of code you wish you didn't have too. Their great time traveling, hot reloading debugger doesn't actually hot reload anymore. And there is no real back end language synergy to speak of at the moment. Many are looking toward Elixir and Phoenix for support instead of more language-similar Haskell options like Yesod and Snap. The competing PureScript, GHCJS, Websharper and FunScript alternatives also complicate the landscape that Elm plays in greatly.

bbcbasic 11y ago
I agree I am learning Elm mainly to learn FRP and do some 'haskell with my hands tied behind my back' because I believe you can get a lot done without resorting to the advanced language features of Haskell. So for me it's a kata for learning how to be a better functional programmer. Once I feel I 'get' the FRP model used I may just go and do the same stuff in another language, see how it plays out in Haskell or Purescript. I feel FP will remain a hobby though and the best I can hope for is to convince .NET colleagues to make immutable classes, use code contracts to avoid null problems, and generally try to minimize state and maybe use Rx. Even F# would be too much of a push for most .NET shops. I have a mortgage and fixing bugs caused by ridiculous state and null references in .NET code pays it and then some :-)
- t1amat 11y ago
  If I may make a recommendation: check out ClojureScript with reagent and re-frame when you feel you've achieved what you set out to in Elm. While Elm nailed the essence of FRP, ClojureScript really nails the experience I was looking for in ways Elm can not. While it doesn't have the gradual typing and fantastic compiler messages, it is also functional and immutable. But to my view it has all around better tooling, very simple FFI (either reference JS already on the page transparently or pull in JS formally via extern definition files similar to TypeScript typings), optional typing via core.typed, sourcemaps with a native debugger, and a node-like full stack synergy through Clojure but with all the power of the JVM. You definitely lose some confidence at run time due to the dynamic typing, but on the whole I think the gains far exceed that. At least for me it's a package that is very hard to beat.