I feel like some things that would be nice to add to and to address in the roadmap explanation as an incentive to want Elm on the back-end would include:
-
I want a server side language with a sufficiently powerful and friendly compiler that if my code compiles it’s got exceptionally strong guarantees to be free from code-induced runtime exception.
I feel like what to do about unavoidable runtime exception for states over long periods of time lays more with the kernel, so maybe an approach like Erlang’s would help for the kernel itself at least: both for handling runtime exceptions and for concurrency.
-
I want a compiler both strict and minimal enough to help make impossible or undesirable states unrepresentable.
-
I want a purely functional, strongly side-effect controlling language on the back end and I want the compiler to support concentrating all side effects (including talking to network client, talking to disk persistence, managing concurrency, etc) into plugins at the kernel so that those kernel-plugins can be drained of as many moving parts as humanly possible. I want to be able to write a majority of my business logic in a realm where I am guaranteed that every function will return the same output from any given set of inputs every single time: a property which greatly improves caching, lazy evaluation, and the effectiveness of testing.
I’m not aware of any other languages that can offer all three of those guarantees simultaneously (especially the one about YAGNI minimalism), so that represents the Elm-shaped hole that I see in the server-side arena. 