[hibikir]

Not quite: It's planned to target Beam, Erlang's VM. It's an easy fit for Elm. Still, not going to get done any time soon.

[ryanplant-au]

Elm on Beam would be some kind of beautiful dream.

[twoquestions]

Do you have a source for this? I'd be interested in their reasoning.

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.

[pmarreck]

I think "massive concurrency" and "bulletproof uptimes" are pretty good reasons. Plus that would then allow Elm on both client and server.

The Elm folks have been fairly buddy-buddy with the Elixir/Phoenix folks, so this doesn't surprise me

[twoquestions]

That sounds amazing.

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.

[adam_albrecht]

Richard Feldman (who works with Evan Czaplicki at NoRedInk) mentioned it in the Elm slack channel.

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.

[knewter]

I think the compile target is basically not a big problem, and there's been explicit work to make the Browser just one Platform. Also, see the `Process` module in the core docs for a hint of the future, regardless of where it lands (this would also work well for WebWorkers etc, and is handled right now by a naive scheduler). Concern over the compile target should be super low - if you've built a language of sorts, you should have a feel for how it's not that big of a deal to tweak the target.

[jtwebman]

This is a great idea as Beam doesn't force typing like JavaScript so it would be a great add. I wonder how they are going to tie in OTP?