5 ms·

> Lunatic's design is all about super lightweight processes. Processes are fast to create, have a small memory footprint and a low scheduling overhead. They are

> Lunatic's design is all about super lightweight processes. Processes are fast to create, have a small memory footprint and a low scheduling overhead. They are designed for massive concurrency. > All processes running on Lunatic are preemptively scheduled and executed by a work stealing async executor. Sounds like Erlang to me.

dnautics 5y ago
Isn't go that way too? Erlang is special for other reasons.
- staticassertion 5y ago
  Sure, lots of languages are like Erlang. Actors and CSP are pretty fundamental patterns. Some things that would make it more like Erlang than Go (but that I won't bother to verify): 1. Go isn't really pre-emptive, it just has a lot of hidden yield points afaik 2. Go doesn't enforce message passing, Erlang obviously does 3. When you send a message to a goroutine that has panicked you hang and, potentially at some point, panic. In Erlang an actor dying can send out a final exit message that other actors (likely a supervisor) can subscribe to. So yeah IDK. To me if it's got lightweight processes, pre-emption, and message passing, it's got everything that makes Erlang special. If it says it's inspired by Erlang I'm going to assume that, along with those things, it also shares goals like fault tolerance.
  - brundolf 5y ago
    "Inspired" is also a highly subjective/pretty broad statement to make. You can have the idea for something while thinking about another thing and not be wrong to say it was inspired by that other thing. I don't see any point saying "you need to justify your assertion that you were inspired by Erlang when working on this project".
  - dnautics 5y ago
    Honestly erlang isn't really preemptive either, it just has a lot of hidden yield points. In earlier iterations (iirc) of the vm, the list length() function was very obnoxiously blocking and would not yield. Erlang doesn't enforce message passing. You can use ets tables to coordinate processes (but don't). A lot of pls claim erlang inspiration, e.g. pony, but miss some very important points and focus on "actors". Erlang isn't even really an actor system at heart, it just looks like it superficially. Actor systems at their core are message and coordination focused; when you write an erlang or elixir program you are typically minimizing the message passing because it is imperformant and hard to reason about. The raison d'etre of erlang processes is not really message passing concurrency, it's failure domain definition and failure domain bundling (if x crashes also crash y, because now the state of y can't be trusted).
    - zelphirkalt 5y ago
      However, by separating out into Erlang's lightweight processes using actors, you enable your code to make use of massive concurrency and thus of what Erlang is good at. From a certain level of concurrency onwards in a big enough problem to solve, the imperformance of message passing becomes less relevant in comparison to being able to process concurrently in many lightweight processes. So one could argue, that indeed some focus on actor systems is not entirely missing the point.
    - staticassertion 5y ago
      > Honestly erlang isn't really preemptive either, it just has a lot of hidden yield points. At some level this is true of all systems - you can't yield in the middle of a `mov`, for example. But as Erlang is interpreted it doesn't rely on yield points. The caveat is that it does if you use CFFI. > You can use ets tables to coordinate processes (but don't). Yeah I'm sure there are endless ways to bypass the intended use of Erlang, I don't think it's really important. This is way different from Go where data is trivially shared across a channel. > The raison d'etre of erlang processes is not really message passing concurrency, it's failure domain definition and failure domain bundling Yes, this is true. The foundation of Erlang is based on earlier research that Armstrong cites in his thesis paper, such as the persistent process and transaction as the basis of system resiliency. But it's not a coincidence he landed on actors to express those things.
  - dmitriid 5y ago
    > Sure, lots of languages are like Erlang. Actors and CSP are pretty fundamental patterns. Actors do not an Erlang make. What makes an Erlang: - Isolation. A crash in an actor cannot bring down other actors. Cannot bring down the runtime In Go `panic` crashes the program. In Erlang "panic" crashes an actor, and... that's it. - Monitoring. The above makes an important property of the system: a process can be monitored, and when it dies you can be guaranteed to receive a message that it died, and why This lets you build things like supervision trees that are impossible/hard/ineffecient(chose two) in other languages. - Everything in the VM is aware of processes, concurrency and parallelism Every process gets its fair share of time: each process gets X "reductions". A reduction is a function call, or a message pass. Each function call or message pass reduces the counter. Once it reaches zero, the process is put on hold, and the next process is run. This means that almost everything in the system, including the VM itself is re-entrant. Even Erlang's regexp implementation is re-entrant. You never even have to think about "wait, if I call this function, and the process is put on hold, what happens". The process will be re-awakened and continued. ---- The first two are what makes Erlang special. The rest is gravy, and there is quite a lot of it on top.
    - staticassertion 5y ago
      Sure. I'm pretty familiar with Erlang's historic roots and motivations and I would agree that isolation is one of those fundamental components.

dnautics 5y ago

Isn't go that way too? Erlang is special for other reasons.

staticassertion 5y ago
Sure, lots of languages are like Erlang. Actors and CSP are pretty fundamental patterns. Some things that would make it more like Erlang than Go (but that I won't bother to verify): 1. Go isn't really pre-emptive, it just has a lot of hidden yield points afaik 2. Go doesn't enforce message passing, Erlang obviously does 3. When you send a message to a goroutine that has panicked you hang and, potentially at some point, panic. In Erlang an actor dying can send out a final exit message that other actors (likely a supervisor) can subscribe to. So yeah IDK. To me if it's got lightweight processes, pre-emption, and message passing, it's got everything that makes Erlang special. If it says it's inspired by Erlang I'm going to assume that, along with those things, it also shares goals like fault tolerance.
- brundolf 5y ago
  "Inspired" is also a highly subjective/pretty broad statement to make. You can have the idea for something while thinking about another thing and not be wrong to say it was inspired by that other thing. I don't see any point saying "you need to justify your assertion that you were inspired by Erlang when working on this project".
- dnautics 5y ago
  Honestly erlang isn't really preemptive either, it just has a lot of hidden yield points. In earlier iterations (iirc) of the vm, the list length() function was very obnoxiously blocking and would not yield. Erlang doesn't enforce message passing. You can use ets tables to coordinate processes (but don't). A lot of pls claim erlang inspiration, e.g. pony, but miss some very important points and focus on "actors". Erlang isn't even really an actor system at heart, it just looks like it superficially. Actor systems at their core are message and coordination focused; when you write an erlang or elixir program you are typically minimizing the message passing because it is imperformant and hard to reason about. The raison d'etre of erlang processes is not really message passing concurrency, it's failure domain definition and failure domain bundling (if x crashes also crash y, because now the state of y can't be trusted).
  - zelphirkalt 5y ago
    However, by separating out into Erlang's lightweight processes using actors, you enable your code to make use of massive concurrency and thus of what Erlang is good at. From a certain level of concurrency onwards in a big enough problem to solve, the imperformance of message passing becomes less relevant in comparison to being able to process concurrently in many lightweight processes. So one could argue, that indeed some focus on actor systems is not entirely missing the point.
  - staticassertion 5y ago
    > Honestly erlang isn't really preemptive either, it just has a lot of hidden yield points. At some level this is true of all systems - you can't yield in the middle of a `mov`, for example. But as Erlang is interpreted it doesn't rely on yield points. The caveat is that it does if you use CFFI. > You can use ets tables to coordinate processes (but don't). Yeah I'm sure there are endless ways to bypass the intended use of Erlang, I don't think it's really important. This is way different from Go where data is trivially shared across a channel. > The raison d'etre of erlang processes is not really message passing concurrency, it's failure domain definition and failure domain bundling Yes, this is true. The foundation of Erlang is based on earlier research that Armstrong cites in his thesis paper, such as the persistent process and transaction as the basis of system resiliency. But it's not a coincidence he landed on actors to express those things.
- dmitriid 5y ago
  > Sure, lots of languages are like Erlang. Actors and CSP are pretty fundamental patterns. Actors do not an Erlang make. What makes an Erlang: - Isolation. A crash in an actor cannot bring down other actors. Cannot bring down the runtime In Go `panic` crashes the program. In Erlang "panic" crashes an actor, and... that's it. - Monitoring. The above makes an important property of the system: a process can be monitored, and when it dies you can be guaranteed to receive a message that it died, and why This lets you build things like supervision trees that are impossible/hard/ineffecient(chose two) in other languages. - Everything in the VM is aware of processes, concurrency and parallelism Every process gets its fair share of time: each process gets X "reductions". A reduction is a function call, or a message pass. Each function call or message pass reduces the counter. Once it reaches zero, the process is put on hold, and the next process is run. This means that almost everything in the system, including the VM itself is re-entrant. Even Erlang's regexp implementation is re-entrant. You never even have to think about "wait, if I call this function, and the process is put on hold, what happens". The process will be re-awakened and continued. ---- The first two are what makes Erlang special. The rest is gravy, and there is quite a lot of it on top.
  - staticassertion 5y ago
    Sure. I'm pretty familiar with Erlang's historic roots and motivations and I would agree that isolation is one of those fundamental components.