- Once you satisfy the compiler you can be fairly sure that code will just work.
- FRP saves you from callback hell.
- Fairly easy Javascript Integration via Ports( also see con on this)
- Time traveling debugger ( see con about this)
- Active mailing list.
- Automatic package versioning which more or less works for the most part
- Pure render function ( popularized by ReactJS), makes writing/debugging UI's trivial and painless.
- "Concurrent" FRP
Cons:
- Javascript integration is very and tedious. You have to declare all your ports in main which breaks abstractions. There is "secret" way of integration via Native modules but this will break if compiler changes ( which does quite often ).
- Debugger/reactor won't work if you have ports, basically all non trivial apps.
- All the ui components have to be reimplemented since stuff like jqueryui/webcomponents don't work ( react suffers from this also)
- No support for isomorphic apps, its a client side only tech.
- Can't do code splitting. Compiler generates one big blob of js.
- Constantly changing terminology ( eg: mailbox)
- IDE's/code editors are on the same level as dynamic languages i.e no code completion, refactoring ect.
- It can separate PureScript modules into nodejs modules
- It has an even stronger type system than elm . For example, typeclasses
- has great interop with javascript
- Because it can compile to node.js modules, and can use node.js libraries, it's actually possible to write a Universal app (I tend to avoid isomorphic, as it means something totall different in pure functional programming languages like PureScript. (https://github.com/paf31/purescript-isomorphisms)).
One issue I have had so far is that once your project gets big, the compile times are pretty annoying. But apart from that; a great language!
How big are we talking about for the compile times?
Is there any in-depth recent comparison of elm and purescript somewhere? I found some links from almost a year ago but I assume it changed a lot since then.
The largest all-PureScript application I know of is SlamData[0], which takes about 12s for a rebuild, but SlamData uses a _lot_ of modules. For smaller projects it's much less. It's not great, but performance is one of three main goals for the current milestone. There is an alternative front-end called psc-compile[1] which reduces the incremental build times considerably. I hope to be able to integrate it soon.
I have used Elm for a couple projects recently and the main benefit is it forces you to program in a maintainable and correct fashion. The community is active and tries to find the right patterns to use without compromising these core principles. I think the potential of a language like this for testable UI's could revolutionize and simplify client side development if it gains enough momentum.
ClojureScript is a lot more mature, with many companies running it in production. The tooling around it is much better, there are many more libraries available, and it provides seamless Js interop.
If you're running Clojure on the backend then you can cross-compile things like validation logic between the two. Use the same build tools and libraries.
My personal impression is that the language infrastructure
is not mature enough. As of version 2.0 you cant install
Elm on Linux platform from npm because of broken repo link
or something (it is known bug but looks like no one cares to
fix it).
But even you managed to install it, Elm itself does not work
behind corporate firewall because it rely on Haskell HTTP
library which suck (they fixed this bug in the library but
please wait for another Elm release for this to work).
The language looks very interesting and promising, I am very
pissed by the fact that I had no chance to try it in our
latest project because of those miserable bugs.
That's really sweet, I have never checked out elm before. I've been contemplating going to TypeScript as it has a good amount of es6 support now, I'll look more at elm though.
I fear something like this though will make it more difficult to hire and on board new people. I'm currently trying to hire 3 senior/very experienced JS developers and that's hard enough.
I'm sure we could keep going, but the point I'm making is that Elm is very close to Haskell, and if you like Elm you will definitely like Haskell. I don't know if the same can be said about going from Haskell to Standard ML because I haven't... yet.
If you're interested in bringing functional/reactive style code to an existing application, you might also be interested in splint.js: https://github.com/adzerk-oss/splint.js
In a nutshell, it's a jQuery-friendly packaging of the ClojureScript runtime and the Javelin cell library, usable in existing applications. You basically write ClojureScript in JavaScript syntax.
Legacy code remains accessible to cheaper contractors, expense of overhauling build/deploy in sunsetting legacy app not justifiable. Gives us the ability to direct most of our effort toward the (Hoplon) all-Clojure/Script replacement.
Pros:
- All the Joys of functional programming .
- Once you satisfy the compiler you can be fairly sure that code will just work.
- FRP saves you from callback hell.
- Fairly easy Javascript Integration via Ports( also see con on this)
- Time traveling debugger ( see con about this)
- Active mailing list.
- Automatic package versioning which more or less works for the most part
- Pure render function ( popularized by ReactJS), makes writing/debugging UI's trivial and painless.
- "Concurrent" FRP
Cons:
- Javascript integration is very and tedious. You have to declare all your ports in main which breaks abstractions. There is "secret" way of integration via Native modules but this will break if compiler changes ( which does quite often ).
- Debugger/reactor won't work if you have ports, basically all non trivial apps.
- All the ui components have to be reimplemented since stuff like jqueryui/webcomponents don't work ( react suffers from this also)
- No support for isomorphic apps, its a client side only tech.
- Can't do code splitting. Compiler generates one big blob of js.
- Constantly changing terminology ( eg: mailbox)
- IDE's/code editors are on the same level as dynamic languages i.e no code completion, refactoring ect.