-
Clojure excels at transforming streams of data. It’s great at taking data flooding in from a network, changing it, and storing it into a database.
-
Clojure code is interoperable with Java programs because it’s compiled to run on the Java Virtual Machine. For Java shops, that means it’s easy to adopt gradually. (It’s just one more JAR!)
-
There is a mostly-compatible implementation, ClojureScript, that runs on the JavaScript Virtual Machine (that is, in-browser). Many open source libraries work in both implementations, and you can write your own libraries to work that way.
-
There is a lot of emphasis on performance. The underlying data structures are tuned to work fast. For many many execution profiles, you can expect performance not too different from Java’s.
-
There’s also a firm commitment not to have new releases break existing programs.
-
Elixir is a language that compiles to the Erlang Virtual Machine. Erlang is a language originally developed by Ericsson for use in telephone switches, where 99.9…9 uptime is required. Elixir inherits both the virtual machine’s and Elixir’s capabilities for robustness and error-recovery. It’s quite an interesting strategy.
-
Elixir is interoperable with Erlang libraries.
-
Elixir seems to have been developed with the explicit goal of gaining lots of early adopters from the Ruby and Rails crowds. (I believe the lead developer was a committer on Rails.) The syntax is similar to Ruby’s. (That only matters in the very beginning, but it’s a good alternative to Erlang’s syntax, which is downright strange.) The web framework, Phoenix, has some similarity to Rails, but I think it’s benefited from knowing which of Rail’s design decisions turned out, in retrospect, to have been sub-optimal.
-
Elixir is much faster than Ruby. Phoenix is much faster than Rails.
-
You don't have to write a web app with Elixir, any more than Ruby can only be used for Rails.
-
Elixir is serious about providing a “whole product”: it doesn’t skimp on good installation and getting the first program running, integration with version control, various kinds of documentation, and so on.
-
I plan to use Elixir for all my future serious backend work.
-
I consider Elm safe for smallish, isolated front end apps. An excellent first use of Elm is to build monitoring apps and other apps that aren’t public facing.
-
That’s not to say that Elm hasn’t been used for significantly more substantial apps, but I personally would be skittish about betting the company on Elm.
-
Elm is a pleasure to use. The error-messages are widely and rightly lauded as being state-of-the-art. Attention has been paid to “fit and finish” - there are many small details that make your life just a little bit better. People in the FP world often underemphasize the productivity benefits of such attention to “affordance”.
-
I moved from Ruby to Clojure to Elm. I found the conceptual gap between Ruby and Clojure much smaller than between Clojure and Elm. The basics of Elm are straightforward, but it took me longer to get good at Elm.
-
That said, Elm is much easier to learn than languages of the algebraic sort (Haskell or PureScript).
-
Of all the languages considered in the talk, Elm is the most vulnerable to the lead developer’s being hit by a bus. The original author of PureScript stepped back from most of his work on the language, and I (a casual user) found the transition seamless. I think a transition would be much rockier for Elm.
-
Elm is very opinionated. For example, although Elm compiles to JavaScript, access to JavaScript native code is awkward and still (I think) sometimes effectively impossible. That’s a common complaint. (For myself, I never missed it, but my needs were always simple.)
-
To me, it’s obvious that there’s a natural growth path from Elm to PureScript, since they’re both derived from Haskell and both target the browser. If you find Elm restrictive, it should be simple to move to the other. My An Outsider’s Guide to Statically Typed Functional Programming was written from that premise.
However, neither the Elm nor PureScript communities are interested in making that happen. From the Elm side, Elm is sufficient and there’s no reason to compromise on the language to ease a switch to PureScript. On the PureScript side, the main adoption is from Haskell programmers, and there’s little overt effort to make adoption by FP novices (which, from a PureScript point of view, includes Elm programmers) easier. (Indeed, some members of the community — though not the core members — say rude things about Elm both as a language and as preparation for “real” functional languages.)
-
Elm’s emphasis on minimal features has consistently led to releases removing existing features (sometimes entirely, sometimes replacing them with simpler features that do the same thing). In my opinion, that’s definitely a net positive for new adopters of Elm, as it gets progressively easier to learn. But it’s really annoying when your existing code stops working.