5 ms·

I'm not sure why you want to compile Elixir or Erlang to JS... Most of the magic of the language is provided by BEAM and OTP which for a multitude of reasons ca

I'm not sure why you want to compile Elixir or Erlang to JS... Most of the magic of the language is provided by BEAM and OTP which for a multitude of reasons cannot be properly implemented in any JS engine/backend I'm aware of. If anything I'd think the abstractions of Elixir/Erlang would be cumbersome and very awkward when writing performant code which had to be transpiled to JS. The biggest reason being is BEAM can do preemptive scheduling, interrupting a running process to ensure all have equal execution time. This is a stark contrast to everything I know about how most any other VM or runtime work (which cannot preempt). While yes the language is nice, I think using something like Opal would provide most of the syntactic pleasantries while being easier to understand when it comes to tuning and debugging. If what I'm saying is nonsense, I'm missing the point, or short sighted please learn me! :)

jaredklewis 10y ago
Even if Elixir had no concurrency goodness I would still prefer it to a language like JS any day of the week. JS is a mess of paradigms and features. Elixir has a small set of great features: modules, functions, pattern matching, immutable data structures, macros. Regarding your performance point, I'm skeptical. Is it really so easy to reason about the performance of even plain JS code? Maybe you're more familiar with the deep dark crevices of v8 and spidermonkey than I am, but I find v8 to largely be a black box in terms of fine tuning performance. Of course, the big picture optimization is simple enough, but that wouldn't change whether you are using plain JS, Opal, PureScript, or any other language. Yes, a BEAM elixir program can run parallel threads and ElixirScript won't be able to do that because in JS, there are no threads. That doesn't make plain JS faster, just means Elixir will be brought down to the same level as plain JS. I've used what I view to be equally foreign compile to JS languages (ClojureScript, Elm). They of course came with challenges, but fine tuning performance doesn't even make the top 10.
btown 10y ago
With the right abstractions and (adhered-to) guidelines, a library in a non-preemptive language can allow your code to effectively yield to the scheduler so often that you get many of the benefits of preemptiveness. React is moving in this direction with their ongoing Fiber project [0] - since components are encouraged to be granular, and must be loosely coupled, the new React scheduler can take well-structured React code and plan the rendering of various subtrees with high levels of control. In fact, there's a TON of similarities between React's component model and the BEAM actor model: a component's "mailbox" consists of inbound props, outbound async callbacks to the component that requested its instantiation, and outbound assertions that the component desires to communicate props to new instances of other components. One could imagine a compiler that inserts a yield around the calculation done in each Elixir AST node, and/or one which allows first-class representation of React components as Elixir processes, complete with JSX-like syntax. Very interesting to think about. [0] https://github.com/acdlite/react-fiber-architecture https://github.com/acdlite/react-fiber-architecture EDIT: Should also add that the shared-nothing messaging model translates very well to the requirements for Web Worker interop, so you actually could get multithreading.
- felixgallo 10y ago
  there's essentially no similarity at all between React's component model and the BEAM actor model, except that there's handlers. React and JS have no notion of backpressure, work-stealing schedulers, NUMA, per-actor GC, the list goes on forever.
  - btown 10y ago
    All true and duly noted, though readers may be interested in how sophisticated Fiber's scheduler may end up being: https://github.com/facebook/react/blob/39278c41e2f98d357f166a5523e3194fc5242d9d/src/renderers/shared/fiber/ReactFiberScheduler.js#L634 https://github.com/facebook/react/blob/39278c41e2f98d357f166...
themgt 10y ago
No I'm totally aware you wouldn't be able to replicate BEAM/OTP on a JS runtime, but my guess is you could port enough of the syntax and some of Elixir's high-level abstractions, especially to ES7. The point wouldn't be running the majority of existing Elixir/Erlang libraries, but to easily write ElixirScript within a webapp and transparently reference/integrate with server-side models, auth, etc.

jaredklewis 10y ago

Even if Elixir had no concurrency goodness I would still prefer it to a language like JS any day of the week. JS is a mess of paradigms and features. Elixir has a small set of great features: modules, functions, pattern matching, immutable data structures, macros. Regarding your performance point, I'm skeptical. Is it really so easy to reason about the performance of even plain JS code? Maybe you're more familiar with the deep dark crevices of v8 and spidermonkey than I am, but I find v8 to largely be a black box in terms of fine tuning performance. Of course, the big picture optimization is simple enough, but that wouldn't change whether you are using plain JS, Opal, PureScript, or any other language. Yes, a BEAM elixir program can run parallel threads and ElixirScript won't be able to do that because in JS, there are no threads. That doesn't make plain JS faster, just means Elixir will be brought down to the same level as plain JS. I've used what I view to be equally foreign compile to JS languages (ClojureScript, Elm). They of course came with challenges, but fine tuning performance doesn't even make the top 10.

btown 10y ago

With the right abstractions and (adhered-to) guidelines, a library in a non-preemptive language can allow your code to effectively yield to the scheduler so often that you get many of the benefits of preemptiveness. React is moving in this direction with their ongoing Fiber project [0] - since components are encouraged to be granular, and must be loosely coupled, the new React scheduler can take well-structured React code and plan the rendering of various subtrees with high levels of control. In fact, there's a TON of similarities between React's component model and the BEAM actor model: a component's "mailbox" consists of inbound props, outbound async callbacks to the component that requested its instantiation, and outbound assertions that the component desires to communicate props to new instances of other components. One could imagine a compiler that inserts a yield around the calculation done in each Elixir AST node, and/or one which allows first-class representation of React components as Elixir processes, complete with JSX-like syntax. Very interesting to think about. [0] https://github.com/acdlite/react-fiber-architecture https://github.com/acdlite/react-fiber-architecture EDIT: Should also add that the shared-nothing messaging model translates very well to the requirements for Web Worker interop, so you actually could get multithreading.

felixgallo 10y ago
there's essentially no similarity at all between React's component model and the BEAM actor model, except that there's handlers. React and JS have no notion of backpressure, work-stealing schedulers, NUMA, per-actor GC, the list goes on forever.
- btown 10y ago
  All true and duly noted, though readers may be interested in how sophisticated Fiber's scheduler may end up being: https://github.com/facebook/react/blob/39278c41e2f98d357f166a5523e3194fc5242d9d/src/renderers/shared/fiber/ReactFiberScheduler.js#L634 https://github.com/facebook/react/blob/39278c41e2f98d357f166...

themgt 10y ago

No I'm totally aware you wouldn't be able to replicate BEAM/OTP on a JS runtime, but my guess is you could port enough of the syntax and some of Elixir's high-level abstractions, especially to ES7. The point wouldn't be running the majority of existing Elixir/Erlang libraries, but to easily write ElixirScript within a webapp and transparently reference/integrate with server-side models, auth, etc.