3 ms·

Before diving into elm, I had this fear too. But speaking from someone who never used haskell before (hell, I never used a statically typed language before), le

Before diving into elm, I had this fear too. But speaking from someone who never used haskell before (hell, I never used a statically typed language before), learning elm was quite simple. There's a lot of help from the compiler and the community as well. After two weeks I was quite confident on my work, and in one month I managed to create the entire architecture of our production app. Through the months I got a better grasp of elm and refactored the entire app several times (not nearly as painful as it sounds). I've made the decision to use elm and put my two frontend devs to learn it. They managed to start contributing to the app in less than a week. So if you have the chance, I think it's worth a shot. I thought I'd never learn elm, but so far my experience proved that it's much easier than it seems.

KurtMueller 9y ago
> Through the months I got a better grasp of elm and refactored the entire app several times (not nearly as painful as it sounds). Refactoring Elm code isn't as painful for me as Javascript or Ruby - because it's statically compiled, it gets rid of a whole class of errors. The compiler does an excellent job at where compilation fails and suggestions to fix the error. Additionally, I find in Elm (and other ML-typed languages) that it's easy to model states of your app (e.g. like a state machine) and events that change the state of your app. Adding/modifying states and events in Elm is one of its strong suits and it really forces you to logically think through how your app transitions from one state to another. Scott Wlaschin has an excellent talk on Domain Driven Design in F# that articulates this point quite well.