[Tehnix]

That's cool.

I've quickly learned that I much more enjoy scrapping redundant code and relying even more on the type system, with things like Higher-kinded types, GADTs, etc.

Elm for me fills the niche of stepping stone into Pure FP (pure as in purity). It's a language I would be able to convince my coworkers to try out, and once they've gotten their feet wet, they can move onto PureScript or GHCJS.

The reason why stopping at Elm, IMHO, is bad, is that it does not foster innovation and trying out things, but restricts itself purely to the subset of what the core team has discovered/learned. This makes it impossible to try out new exciting things like this "A proof-of-concept UI library based on the incremental lambda calculus"[0] that does away with the need for VDOM diffing, and other interesting things.

Don't get me wrong, there is certainly appeal to having a simple language that everyone can quickly master (like Go), but it isn't the be all end all.

[0] https://github.com/paf31/purescript-purview

[always_good]

I mainly use Elm these days because it does exactly what it says on the tin: it helps me build robust client-side applications and fight off technical debt, which is a harder problem to solve than accumulating abstractions.

It's kind of like how Java and Go are shitty when all you want to do is masturbate over clever solutions, but there's something to appreciate about them for that same reason.

[vmchale]

Not to mention it actively removes features that are heavily used. An egregiously disrespectful way to treat your library authors and community members, frankly.