It’s not really the syntax that makes Elixir great, it’s the runtime, and neither OCaml nor JS have similar runtimes.

I think transpilation of a language into a radically different runtime is more trouble than it’s worth- you have to write your code completely different and there’s not really a lot of code sharing that actually happens between runtimes.

Transpiling Elixir into whatever is definitely possible and probably not too difficult, at least the sequential part of the language. However, without all the “systems stuff” like processes, concurrency, error handling, all the goodies in the BEAM, etc etc it is actually pretty useless. It is the system building parts of Erlang/Elixir which are the truly important parts and they are definitely the most difficult parts to implement.

Having worked on ElixirScript, I mostly agree with what @rvirding said. Thanks to the work that the Elixir Core Team put into Elixir 1.5 and Erlang 20, it is relatively easy to compile Elixir to another target. The useless part is almost correct. There are a lot of expectations. Most of them inside of the BEAM and ElixirScript fails to live up to those these days. The FFI though does allow one to treat it similarly to things like BuckleScript though.

All is not lost though. Any efforts to do anything of this sort should focus on the BEAM characteristics first.

Couple of videos (on opinions) why transpiling from a sound to a loose language may be a good idea when we are talking about the JS eco-system.

With the BEAM matters are more difficult because of typing the contents of the process mailbox which is largely the result of dynamic sends and receives.

ElixirScript can provide most of what you describe today. A transpiler that does not support processes, code sharing between front end and back end, an ffi, ability to create packages that can be placed in hex. If those are the goals, it’s pretty close. Could probably use more work in the user friendliness and doc departments though.