1. 21
  1.  

  2. 9

    This looks pretty cool! I definitely see the resemblance to Erlang’s model of lightweight processes. That said, I couldn’t find the primitives upon which Erlang’s supervisors are built; links and monitors.

    The idea of uni- or bi-directional links between processes seems to be more flexible and powerful than representing supervisor trees directly in code. Two examples come to mind:

    1. Process A waiting for a response from process B, but process B crashed after receiving the message from A. This could be solved by having process A create a uni-directional link (‘monitor’ in Erlang) to B before sending the message.

    2. Process A is responsible for maintaining state about a set of other processes managed by one or more supervisors. With links in Erlang, this is easy, and with trap_exit, process A can see how these processes exit, and update its state accordingly.

    With supervision trees, you gain the ability to manage how some groups of processes are managed. With links and monitors, you gain the building blocks on which Erlang’s supervision trees are built, and much more.

    1. 6

      First of all, I would like to thank you because this is one of the most constructive comments I have ever received over the course of 6 months.

      I am going to reflect that mechanism over to Bastion. The cases you’ve mentioned were the cases bugging me for a while. I added your comment as an issue on project’s issue board

    2. 3

      So if I’m reading this right, I would want this because I want actors in rust.

      Is this more like pony (actors in a single process managing across processes is an exercise for the user) or like akka/erlang (lots of stuff for working with multiple os-level processes).

      And on the other dimension is this “let it crash” actor supervision or “static analysis makes it hard to write actors that crash”?

      Edit: reading the front page again it looks like it’s supposed to erlang style easily federated and let it crash.

      1. 1

        Edit: reading the front page again it looks like it’s supposed to erlang style easily federated and let it crash.

        Yes exactly. That’s the roadmap of the project.

        1. 2

          Do you have a rundown of what’s real and what’s planned?

          1. 4

            Basic near future planned things:

            • Stabilizing unstable features.
            • Distributed carrier protocol.
            • Faster runtime with a more advanced scheduler.

            The real part is what is written in the readme:

            • Fault tolerance against panic mechanism
            • Dynamic message dispatch
            • Dynamic supervision
            • Nearly the same scheduler that Erlang has.

            Far future plans:

            • HCS (hot-code-swap)
      2. 2

        This should be interesting… combining the low-level performance of Rust and the bomb-proof nature of the BEAM sounds great on the surface.

        1. 1

          Does it support live updates, that is, releasing new code without restarts?

          1. 2

            Not yet, we are looking forward to having HCS in the long term.