> but all that really means is: "I don't know how to do this in a simpler way, so I need the "advanced" language features..." I disagree with most of your comm

> but all that really means is: "I don't know how to do this in a simpler way, so I need the "advanced" language features..." I disagree with most of your comment, but I want to respond to this one section in particular. I enjoy using PureScript in place of languages without the "advanced" features because it lets me express things that are otherwise _not expressible_. That doesn't make the language more complex, or less "simple" if you prefer, but it _does_ arm its users with the tools necessary to create more powerful abstractions, should they need them. Will some of these abstractions end up introducing more complexity? Perhaps. However, one can write simplified code in a language that admits more powerful abstractions while the reverse _is not true_. When someone decides that they don't want to use higher kinded types or typeclasses in PureScript, they can _choose_ not to use them. When someone runs into a problem that would be made easier with higher kinded types or typeclasses in Elm, they _cannot choose at all_. Nowhere is this point driven home more clearly than when deriving JSON encoders and decoders. The last time I checked, users were advised to codegen complex JSON codecs using a web app [0]. Compare this with PureScript, where the language's features can be used to automatically derive JSON codecs from a simple type alias that looks nearly identical to the JSON itself [1]. And these are just two features that are directly comparable. A few months back, I gave a talk on how these "advanced features" can be used to construct functions that can be combined to create complex pieces of input validation logic. These functions can be safely mixed, matched, and extended with strong guarantees that any and all failures will be propagated back to the caller in the form of typed error messages [2]. Anyway, I'm sorry if this rant was just the result of me having read farther into that one part of your comment than you intended. I don't think there's anything wrong with people using Elm, and I'm glad that there are more avenues into strongly typed, functional programming than just Haskell and PureScript. I just see this line of "Elm is simple" brought out in response to these other languages, and feel that it entirely misses the point of why those languages added the features in the first place. [0] https://noredink.github.io/json-to-elm/ https://noredink.github.io/json-to-elm/ [1] https://github.com/justinwoo/purescript-simple-json https://github.com/justinwoo/purescript-simple-json [2] https://www.slideshare.net/JosephKachmar/lc2018-input-validation-in-purescript https://www.slideshare.net/JosephKachmar/lc2018-input-valida...