3 ms·

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

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.