Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
Elm vs PureScript -- I've typed this or something similar enough times to just stick it in a Gist : ]

I'm convinced one of them (or something similar) will be the future, but it's too soon to say for sure. The Elm community is growing crazy fast and it's really focused on being beginner-friendly and having a good dev experience (see this recent talk from Elm's creator: https://www.youtube.com/watch?v=oYk8CKH7OhE). This focus has kept the language simple and lots of work has been done on making the compiler errors helpful and instructive. Elm also limits communication with JS to an interface called 'ports', basically just message passing that both sides must parse and act on. Elm also has focused pretty exclusively on coding client-side UIs (i.e. the Angular or Ember or (most similarly) React+Redux space)

PureScript is a similar idea (a statically typed functional language compiling to JS), but with a different background and different short-term goals. PureScript modules compile to CommonJS modules. PureScript functions compile to JS functions. The FFI (talking to JS code) is more like TypeScript or Flow, where you define the foreign types in a PureScript file and tell the compiler to trust you (rather than passing strings through a 'port')

This makes FFI easier and faster, but also more dangerous.

PureScript also aims to produce readable JS, so it can be used and understood without souremaps if necessary. It also doesn't have a runtime, like Elm, resulting in smaller, more flexible output (you can target browsers, cli apps, node, aws lambda, etc)

PureScript also has a more complete type system, in some ways more modern than Haskell's. It makes it less approachable for people with no Haskell experience, but allows more powerful abstraction than Elm provides

This is an intro to PureScript and its JS output from a recent meetup I presented at: https://www.youtube.com/watch?v=9a57V3bvzaI

A little example to highlight that difference (Elm is currently a UI building language, PureScript is just a different way to write JS) is that currently both the Elm and PureScript compilers are written in Haskell, and the PureScript build tool, Pulp, is written in JS. But both PureScript itself and Pulp are in the middle of being rewritten in PureScript. I don't know of any plans to do that with Elm in the near future. The PureScript compiler is also being built with compiling to multiple backends in mind (JS, LLVM, maybe Lua)

Elm will slowly adopt things from PureScript and vice versa. Either Elm will be a stepping stone or learning platform to eventually jump to PureScript, or PureScript will prove too steep a learning curve for most people's needs and it'll become niche or die out. In the meantime, the competition will improve both languages : ]

Interesting. Maybe there's room for both on one project? Maybe the front-end in Elm, to be more approachable to front-end devs who are just starting, and the server in Purescript for the server-side persons who are possibly more likely to be experienced with advanced type systems?

I believe Elm will win on the front end due to the fact it is much more "friendly" for such developers. Purescript will be competing mainly against Clojure on the backend.

crocket commented Mar 31, 2016

On the backend, you can just use haskell instead of PureScript on a headless javascript runtime.

doppioslash commented May 12, 2016

I think Elm can definitely be a stepping stone to Purescript/Haskell.
It's way easier to get started with, and now it's explicitly optimised for ease of learning and ease of use.
It gets people new to FP used to syntax, types-first development process, and many pure FP basics.
But the extreme simplicity makes it frustrating once you grow out of its box, and want to tackle more complex concepts, or want to have a different program structure than the prescribed one.

Therefore there is a natural progression, people just interested in doing what Elm is best at, will likely just stick with it, but those who find it too restrictive after a while are going to look at Purescript.
A moderate effort to make Purescript friendlier would probably have a good return on investment, without going to Elm's lengths though :P
I think in the purescript-elm readme a lot of small syntax conveniences are covered, that are worth a though of including them into Purescript: eg. tuple literal syntax.

I just came across this and thought I'd comment. 😄

Elm will slowly adopt things from PureScript and vice versa. Either Elm will be a stepping stone or learning platform to eventually jump to PureScript, or PureScript will prove too steep a learning curve for most people's needs and it'll become niche or die out. In the meantime, the competition will improve both languages : ]

I don't think this is how it will play out. I see Elm and PureScript as like Ruby and Python: two different philosophies with a lot in common, destined to coexist.

Python is a very popular teaching language, much more so than Ruby. This beginner-friendliness does not mean that Python is overly simplistic or that Ruby is superior for serious projects, it just means that Python's design seems better suited to that use case. The same is true here. Elm is no more "PureScript for beginners" than Python is "Ruby for beginners." They just have different designs.

In both pairs of languages (Python/Ruby and Elm/PS), if you like one, you'll probably like a lot about the other. Still, some Ruby users find Python's significant indentation intolerable, and some PS users find Elm's lack of user-defined typeclasses intolerable. Neither fact means Python is going to do away with significant indentation, or that Elm is going to add user-defined typeclasses. Both are design decisions that attract some programmers—greenhorn and veteran alike—and alienate others.

People will gravitate toward one language or the other based on personal preference. That's how it is today, and I think that's how it will continue to be!

Owner

spicydonuts commented Jul 12, 2016

That's a good way to look at it! I should refresh this soon too.. I wrote it a long time ago and was mostly just thinking aloud. There's a lot of cool work happening in both communities and it'd be neat to touch on tooling, editor plugins, popular libraries (especially UI), and near-future roadmaps.

trylks commented Aug 2, 2016

I'm on the fence on this one. Both languages, and Haste, (and ClojureScript) are interesting to me.

So far my experience in the JavaScript world is limited to CoffeeScript and it's been a frustrating one at times. E.g. Jasmine using an older CoffeScript version and producing parser errors in perfectly fine code.

In principle, all these languages are nice and beautiful, but at the end of the day I want a language that works, one that I can use at work to avoid (the PITA of) JavaScript. That involves using the JavaScript libraries that are available and having nice tools, either adapted from JavaScript (grunt supports .coffe configuration) or other languages (leiningen for ClojureScript).

Therefore it's probably unavoidable but sad nonetheless that the efforts in the development of the ecosystem are fragmented among several languages. In this context, if I had to choose, I would probably go with Scala.js (types + decent support). But the fact is that I'll stay on the fence a bit longer.

bobzhang commented Aug 4, 2016

Would you checkout BuckleScript also? It is a mix of PureScript and GHCJS, like GHCJS, it does not invent a new language, it is a backend for OCaml, and like PureScript, it generates readable JS, even its compiler can be compiled into JS (https://bloomberg.github.io/bucklescript/js-demo/).

zkessin commented Nov 1, 2016

What @rtfeldman said, i think PureScript and Elm will both continue to exist just like Ruby and Python. They have similar but different use cases. I also hope that they both learn from each other

zvozin commented Mar 7, 2017

Successful languages succeed because they lopsidedly solved a specific problem. Python - bio-informatics and stats. Ruby - not being J2EE. C - Unix. Elm - Angular/React/Babel/TypeScript/Grunt/Bower/ES2015/ES6/Promises/etc exhaustion. PureScript - ?

sjfloat commented Mar 18, 2017

I'm deep into an Elm project at the moment. I am one of those who are frustrated by its limitations as compared to something like Haskell or OCaml. But at this point, the main reason I wish I had chosen Purescript instead is that I would really have benefited greatly from being able to share frontend code on the node-based backend, like the clojure/clojurescript folks are able to do.

However, given the choice between Elm and bare javascript, Elm has been immeasurably preferable. I'm very grateful that it's available.

A core difference left out above in the Elm/PS -> Python/Ruby comparison is that Purescript is general purpose, while Elm is not. Elm's compiler will never be self-hosted for this reason.

The main Elm compiler will not, but there already exists an almost complete Elm parser written in Elm and I am writing a type inference. I would not be surprised if there is Elm in Elm next year.

jvarness commented Aug 6, 2017

I think that what the author of the Gist said about a lack of abstract types in Elm is what's sort of holding it back from being a language that could be more useful in enterprise settings. However, Elm does aim for consistency and simplicity as a paradigm. Does a type need to be abstract if you're just creating a web frontend? Are you over-thinking your design?

With libraries like elm-route and elm-navigation, Elm has the capability to fit those use cases where you would want a SPA with different pages. I also like the thought of being able to write React Native apps in Elm as well using elm-native-ui like the author or Purple Train did.

I would also say that if you aren't used to functional languages that Elm does have a bit of a learning curve, and if you aren't so familiar with the syntax, it can be a little tricky to learn, but the overall experience with developing Elm applications is pretty delightful.

granteagon commented Sep 14, 2017

Why are both Elm and PureScript making whites pace important? I think this is a big design flaw. And don't misunderstand me, I know Python and CoffeeScript but guys on my team HATE languages that are not c-like in syntax. Adoption of a language that makes white space important is almost doomed IMO because of this.

I think the problems that Elm and PureScript need to solve are strong typing, easy documentation and bringing FP into the real mainstream (currently on the fringe of the mainstream IMO). Don't make white space the cross these languages die on.

hzamir commented Oct 24, 2017

@granteagon: They are inspired by Haskell and many similar functional languages. All functions are curried in Haskell, and the whitespace is in itself "function application". (For example, any function that nominally takes 3 arguments, can be called with only two arguments and return a function that just requires the third. Or it can take only one argument and return a function that just requires the remaining two). So: f a b c is like (f a) b c, is like (f a b) c

This is not just a random choice, it is an elegant solution that goes to the core of what the language attempts to do.
We all need to get over our biases about syntax. Yes, I loved curly braces for twenty years, but bit the bullet to learn Ruby and put up with begin end, because otherwise, Ruby was just too good to pass up. Yes, I too was horrified at using pure indentation to indicate nesting in Python, but my advice is simply to GET OVER IT. Learn to read Haskell first, and you will change your mind. Come back to PureScript and you will probably be complaining it isn't even more like Haskell.

Actually "Ports" is an idea not new to Elm, the roots of "Ports" comes from Scheme.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment