4 ms·

Coming from Ruby, Elixir feels like a powerful, beautiful language with a surprisingly radical but ultimately simple approach to concurrency thanks to Erlang/BE

by themgt 10y ago

Coming from Ruby, Elixir feels like a powerful, beautiful language with a surprisingly radical but ultimately simple approach to concurrency thanks to Erlang/BEAM, and Phoenix is like Rails 2006, as far as the framework to sell Elixir's advantages to the masses. It's very powerful and scaling "just works". All Elixir needs now is a viable ElixirScript that can compile down to JS/WASM, and along with Nerves it's ready for world domination. ;)

pmontra 10y ago
If all you need in js/wasm is the functional layer of the language, that could be easy. If you want to add processes, that could be very hard. If you also want the supervisors, that's difficult but probably not has much as adding Erlang style processes.
- pmarreck 10y ago
  What's stopping a compile of Erlang to JS via LLVM and Emscripten and just taking the expected performance hit?
  - Xixi 10y ago
    Erlang doesn't compile to machine code, but to bytecode that runs into the Erlang VM. So you would probably have to run the Erlang VM on top of javascript... I'm not sure whether it's possible, but it sure sounds heavy.
    - int_19h 10y ago
      With WebAssembly, you should be able to compile the Erlang VM itself to it.
  - bryanjos 10y ago
    There is the LLVM backend in Erlang as of version 17. I haven't seen much info on it. I haven't seen anyone try to go the whole process from Erlang code to LLVM to Emscripten to JavaScript. I am interested to know what hurdles there might be, performance, etc.
- lawik 10y ago
  AFAIK the VM creates a thread per core (by default) and schedules Processes across those threads and stuff. I'd say this might be possible to do with Web Workers. Sounds like it could be fun, probably a challenge to make it fast.
chao- 10y ago
>All Elixir needs now is a viable ElixirScript that can compile down to JS/WASM On the off-chance you pulled that name out of a hat, or for the benefit of anyone else who might not realize you are referencing a real project: https://github.com/bryanjos/elixirscript https://github.com/bryanjos/elixirscript
rubyn00bie 10y ago
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.
retrogradeorbit 10y ago
Just use elixir on the server, and clojurescript on the client.
- kim0 10y ago
  Or clojurescript on both sides

by themgt 10y ago

pmontra 10y ago

If all you need in js/wasm is the functional layer of the language, that could be easy. If you want to add processes, that could be very hard. If you also want the supervisors, that's difficult but probably not has much as adding Erlang style processes.

pmarreck 10y ago
What's stopping a compile of Erlang to JS via LLVM and Emscripten and just taking the expected performance hit?
- Xixi 10y ago
  Erlang doesn't compile to machine code, but to bytecode that runs into the Erlang VM. So you would probably have to run the Erlang VM on top of javascript... I'm not sure whether it's possible, but it sure sounds heavy.
  - int_19h 10y ago
    With WebAssembly, you should be able to compile the Erlang VM itself to it.
- bryanjos 10y ago
  There is the LLVM backend in Erlang as of version 17. I haven't seen much info on it. I haven't seen anyone try to go the whole process from Erlang code to LLVM to Emscripten to JavaScript. I am interested to know what hurdles there might be, performance, etc.
lawik 10y ago
AFAIK the VM creates a thread per core (by default) and schedules Processes across those threads and stuff. I'd say this might be possible to do with Web Workers. Sounds like it could be fun, probably a challenge to make it fast.

chao- 10y ago

>All Elixir needs now is a viable ElixirScript that can compile down to JS/WASM On the off-chance you pulled that name out of a hat, or for the benefit of anyone else who might not realize you are referencing a real project: https://github.com/bryanjos/elixirscript https://github.com/bryanjos/elixirscript

rubyn00bie 10y ago

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.

retrogradeorbit 10y ago

Just use elixir on the server, and clojurescript on the client.

kim0 10y ago
Or clojurescript on both sides