6 ms·

Am I understanding this right that it's actually implementing the actor model just like Erlang? It seems to have processes and you can send them messages. The

by hopia 7y ago

Am I understanding this right that it's actually implementing the actor model just like Erlang? It seems to have processes and you can send them messages. The threads seem really lightweight, but how would some typical frontend benefit from this?

bcardarella 7y ago
> how would some typical frontend benefit from this At ElixirConf I built a simple supervisor DOM tree model. When we are ready to implement it for real we're going to experiment with mapping the DOM to a supervisor. Each node being an element. This way events and rendering take place in each node in the supervisor tree. Rendering would be diff based and merged its way back up. Events would be captured as messages in the idiomatic Erlang/Elixir way. This is all guess work right now and we don't yet know what will be practical vs what sounds good in theory. However, we are dedicated to the idea that the programming model of the BEAM is one that complex client-side applications will benefit from over what JavaScript current offers.
- mstade 7y ago
  This sounds like an interesting experiment, do you have a repo or anything one could follow?
  - bcardarella 7y ago
    https://github.com/lumen/db_mon_demo https://github.com/lumen/db_mon_demo There is a db_mon-esque implementation within the source and ultimately this is where the demo will live but for now (and the purposes of that demo at ElixirConf) I went in a different direction
- hopia 7y ago
  Oh wow sounds like a pretty fundamental overhaul of the current DOM model. Then again, various virtual DOM diff implementations have shown they can improve working with the DOM a lot.
  - hsavit1 7y ago
    Yeah, the undertaking would be quite extraordinary if they could get it working. Something tells me that this is going to take a few years to develop (preemptively giving a "bravo" if it could be done sooner ;) )
- lawik 7y ago
  That sounds pretty close to what Scenic does for OpenGL-rendered UI. Scenic has some interesting properties in that if a specific component has a code problem and fails/crashes, the supervision tree will bring it back to life. I'm curious to see what similar things one could do with Lumen for the web. Components are already a very popular level of abstraction with Vue and React, probably others. So maybe there are useful things to bring from Scenic.
  - bcardarella 7y ago
    Scenic is one area that I've looked to for inspiration on what a GUI can be like in Elixir
lawik 7y ago
It will run Erlang and Elixir. So anything you like or dislike about working with those languages should carry over. I find them delightful, mostly have experience with Elixir. Asynchronous and event-driven code is already a fact in the browser so working with an ecosystem that is designed for that may prove a better experience. I'm hopeful. Also, concurrency, staying of the render thread if possible. There's lots of fun to be had there.
- hopia 7y ago
  Supervisors, Genservers etc. are OTP patterns, not specifically Erlang or Elixir language features. Lumen seems to implement OTP patterns so that's why those things work on it.
  - lawik 7y ago
    Yeah, I'm aware of the distinction. But I honestly haven't settled on how to refer to it all as a whole. Do you have a preference?
    - hopia 7y ago
      I didn't mean to nitpick about the definitions, I just wanted to say Erlang/Elixir would both be well usable as languages even without the OTP abstractions and tooling.
      - lawik 7y ago
        That's a fair point :)
regulation_d 7y ago
For me, the main benefit would be the ability to use a concurrency model other than the event loop. In Elixir, I can reason about the code being run in one process as though it were synchronous, because it kind of is. But I can do that without blocking anything else, which is also pretty important.

by hopia 7y ago

bcardarella 7y ago

> how would some typical frontend benefit from this At ElixirConf I built a simple supervisor DOM tree model. When we are ready to implement it for real we're going to experiment with mapping the DOM to a supervisor. Each node being an element. This way events and rendering take place in each node in the supervisor tree. Rendering would be diff based and merged its way back up. Events would be captured as messages in the idiomatic Erlang/Elixir way. This is all guess work right now and we don't yet know what will be practical vs what sounds good in theory. However, we are dedicated to the idea that the programming model of the BEAM is one that complex client-side applications will benefit from over what JavaScript current offers.

mstade 7y ago
This sounds like an interesting experiment, do you have a repo or anything one could follow?
- bcardarella 7y ago
  https://github.com/lumen/db_mon_demo https://github.com/lumen/db_mon_demo There is a db_mon-esque implementation within the source and ultimately this is where the demo will live but for now (and the purposes of that demo at ElixirConf) I went in a different direction
hopia 7y ago
Oh wow sounds like a pretty fundamental overhaul of the current DOM model. Then again, various virtual DOM diff implementations have shown they can improve working with the DOM a lot.
- hsavit1 7y ago
  Yeah, the undertaking would be quite extraordinary if they could get it working. Something tells me that this is going to take a few years to develop (preemptively giving a "bravo" if it could be done sooner ;) )
lawik 7y ago
That sounds pretty close to what Scenic does for OpenGL-rendered UI. Scenic has some interesting properties in that if a specific component has a code problem and fails/crashes, the supervision tree will bring it back to life. I'm curious to see what similar things one could do with Lumen for the web. Components are already a very popular level of abstraction with Vue and React, probably others. So maybe there are useful things to bring from Scenic.
- bcardarella 7y ago
  Scenic is one area that I've looked to for inspiration on what a GUI can be like in Elixir

lawik 7y ago

It will run Erlang and Elixir. So anything you like or dislike about working with those languages should carry over. I find them delightful, mostly have experience with Elixir. Asynchronous and event-driven code is already a fact in the browser so working with an ecosystem that is designed for that may prove a better experience. I'm hopeful. Also, concurrency, staying of the render thread if possible. There's lots of fun to be had there.

hopia 7y ago
Supervisors, Genservers etc. are OTP patterns, not specifically Erlang or Elixir language features. Lumen seems to implement OTP patterns so that's why those things work on it.
- lawik 7y ago
  Yeah, I'm aware of the distinction. But I honestly haven't settled on how to refer to it all as a whole. Do you have a preference?
  - hopia 7y ago
    I didn't mean to nitpick about the definitions, I just wanted to say Erlang/Elixir would both be well usable as languages even without the OTP abstractions and tooling.
    - lawik 7y ago
      That's a fair point :)

regulation_d 7y ago

For me, the main benefit would be the ability to use a concurrency model other than the event loop. In Elixir, I can reason about the code being run in one process as though it were synchronous, because it kind of is. But I can do that without blocking anything else, which is also pretty important.