Hacker News Reader

Comment by twoquestions | Hacker News Reader

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.

View on HN

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

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.

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.

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.

Reply on news.ycombinator.com