My answer to this has changed quite a bit over the last year. It used to be the case, at least as I saw it, that Elm had a UI focus, and PureScript tried to be

My answer to this has changed quite a bit over the last year. It used to be the case, at least as I saw it, that Elm had a UI focus, and PureScript tried to be a general-purpose language. So it came down to typical expressiveness vs. tooling/analysis tradeoffs. You could use Elm and maybe sacrifice some general-purpose language features like dealing with arbitrary effects, but buy yourself best-in-class tools like their excellent time-traveling debugger, and hot code reloading. Or you could pick PureScript, and have a general-purpose language which ran in a bunch of environments with lots of native libraries, but at the expense of tooling. Now though, Elm has become a more general-purpose language, adding effects and various other features, and PureScript has better UI libraries and tooling/editor support. So the gap has closed somewhat. Speaking generally, the goals of the two projects are pretty similar. I can't speak for the Elm community, but "bring strongly-typed FP to the JavaScript community via the web platform" seems to approximate the goals of both projects pretty well (maybe someone from the Elm side can correct me here?) So the goals are similar, but the execution is very different. I think Elm and PureScript differ greatly in opinions regarding _how_ to bring strongly-typed FP to JavaScript. This is not just a question of language features (type classes and HKTs are often mentioned), but also things like how the language should present its foreign function interface to JavaScript, what the entry point to an application should look like, whether to build features into the language or in libraries, how to grow a language community, etc. In practice, these make the experience of using each language very different. > when would we want one vs. the other? Elm provides tools with which you can become productive quickly. Also, it's used in production by NoRedInk and others, so it's clear that it is general-purpose enough to be used for real applications. I think there will be two paths to PureScript for most users - from Haskell, and from JavaScript, quite possibly via Elm. Just as users might move to Elm because they want type safety and expressiveness, they might move to PureScript because they find themselves wanting even more type safety and expressiveness. Certain abstractions are possible in PureScript, but (I think, again, would be glad to be corrected..) not in Elm - free monads, monad transformers, monadic tail calls, van Laarhoven lenses, etc. SlamData is an example of an (open source) company putting these tools to great use.