It would be really cool to have an Elm type language on the backend. Elm feels like a lighter, friendlier version of Haskell.
No typeclasses, no monads, more primitive pattern matching, no guards, use of massive nested elseif considered idiomatic ...
Simple tasks wind up feeling tedious because so many of the standard tools and patterns of any other ML language are simple missing completely. The result feels like trying to work with one of those random toy Lisps people make in a weekend and throw up on Github.
It frustrates me, because in theory I do like the concept of the Elm architecture, I love ML-style type systems, and I work with reactive programming every day in ClojureScript. But the language it's attached to is so incomplete that it quickly just becomes a pain.
Javascript dev sees Elm and might think "Wow,a type-system and it is awesome, didn't expect that"
Haskell dev sees Elm and might think "I am missing so many features with these types" and consider something else, probably pure-script, that has similar toolbelt.
Not sure about the rest though.
I'm currently using it in production with purescript-thermite, a thin wrapper over React, and it's worked out great.
Elm is great for people coming from JS, but not so much for people coming from Haskell.
On the other hand, OCaml also targets JavaScript coding in the browser, via js_of_ocaml or the newer bucklescript.
I would be very interested in a comparison of client-side development with OCaml+js_of_ocaml (or OCaml+bucklescript) versus Elm.
You'd think Beam would be a very different compile target than JS, and it seems weird to make such a huge change without very good reason.
The Elm folks have been fairly buddy-buddy with the Elixir/Phoenix folks, so this doesn't surprise me
It makes my heart sing that a different VM than JVM or .Net is gaining more traction, and as a static types fan it makes me happy that a statically typed language may be getting on Beam.
http://i.imgur.com/pqk9oMl.png
It will definitely be a very different compile target. But Elm really doesn't take any inspiration from Javascript, so I don't think it will change much about the fundamentals of the language. Of course they'll need to add capabilities for concurrency, OTP, etc.
I'd just looove to try and put Elm on the JVM, but I just can't at the moment.
http://learnyousomeerlang.com/dialyzer
But is still optional to compile. The more precise and better the type annotations, the more helpful it is. If it can deduce that some inconsistency or type error occurring it will let user know. If it is not sure, it won't say anything.
Another point is because of isolated process heaps and extra fault tolerance, it is possible to get a high degree of assurance from a system built in Erlang or Elixir even with dynamic typing. And there are certainly many examples of that.
Elixir also follows the Ruby philosophy of hiding as much behind the syntax as possible, whereas Elm tends to be very explicit. So I stand by my point that Elixir is a very different language in practice from Elm.
This is not true. While Elixir may not make things as explicit as Elm (I don't know Elm well enough to assert or refute such a statement), the author of Elixir has stated in various occasions that Elixir prefers explicit to implicit.
For instance, in Elixir, unless one explicitly defines a String.Chars protocol for a data structure, string interpolation of that data structure will not compile. In contrast, pretty much everything can be implicitly interpolated in Ruby.
Another example is function calls. In Elixir, if f is not a named function but a variable bound to an anonymous function, you cannot call it by writing something like f(x). Instead, you must put a dot after f and write f.(x) to state clearly that you are calling an anonymous function.