4 ms·

Tail call elimination isn't always possible, but it's the gateway drug to continuations which are always possible, and continuations are the gateway drug to act

Tail call elimination isn't always possible, but it's the gateway drug to continuations which are always possible, and continuations are the gateway drug to actors, and once you have actors you're free to move any element of your program anywhere, break it into pieces and put them back together, go nuts, it just works--and now you're able to write code on asynchronous million-node networks without having to worry about locks, mutating global data, shared stuff, and everything else that gets in the way of using modern hardware.

tsimionescu 7y ago
If you have code that doesn't need to mutate data, it is already easy-ish to write on whatever scale you want. The problem is that there are very few algorithms and business problems that don't require shared state to work. I'm not sure how actors or continuations could solve the problem of creating a distributed database of clients, or even of computing histograms on data in parallel, significantly more easily than more traditional programming paradigms.
- toast0 7y ago
  Rather than accessing the shared data directly, you send a message to the actor that owns that piece of shared data, that message could be a request for some data, or a request to modify it in some way. The actor that owns the data reads its mailbox of requests and processes them without worrying about locks and things, because it has exclusive access. The actor that needs to access the data doesn't worry about locks and things because it's not directly accessing it, it's just sending a message. The system worries about locks and things, because the message mailboxes are shared state to some extent. If you can cleanly separate ownership of different pieces of data into different actors, you get parallelism. If there's too much dependency between the pieces of data, so that separating ownership makes things more complex, maybe that becomes more visible.
  - tsimionescu 7y ago
    That sounds nice, but it means that all reads and writes are serialized. You can't scale a system like this to, say, work for sign-up and retrieval of all Gmail users.
    - toast0 7y ago
      To scale up, you need to partition/shard the space. For gmail users, you could hash on the (normalized) username, and all users with hash between A and B would go to one actor, etc. You don't need (or want) parallelism for signup on a single user id, but you could hash or otherwise divide that work to that level. You can also do a partitioned work queue with a (smallish) worker pool per partition; and have the queue keep track of any keys with a current worker, to assign further work to that worker (to avoiding parallel work on the same key and the locking that requires)
      - tsimionescu 7y ago
        These are elegant solutions, but they are also rather complex, and I'm sure that if we dig in deeper there are further complexities to explore. I have no doubt that the actor model or continuations can be used to solve any problem. I do however doubt that it would turn out to be simpler than using shared state and explicit locking; or using ledger-like approaches. I also don't think it would be more complex! I believe that problems of distributed computing are inherently hard enough that the incidental complexity from your chosen modeling approach is not likely to be a significant portion of the overall complexity.
        toast0 7y ago
        The nice thing, if you do it right, is that each piece is going to be simple. There may well be emergent complexity in how the simple parts go together, but that's going to happen anyway. Might as well make the parts simple where you can. Incidentally, I think email is a great example of something with clear divisions of work --- an actor could easily be responsible for a single user's mailbox, and there should be no overlap in responsibility. Possibly, you could have one actor per folder, but gmail doesn't really have folders, so...
eru 7y ago
Well, you will only have to worry about mutable global data if that's what your solution calls for. Essential complexity vs accidental.

tsimionescu 7y ago

If you have code that doesn't need to mutate data, it is already easy-ish to write on whatever scale you want. The problem is that there are very few algorithms and business problems that don't require shared state to work. I'm not sure how actors or continuations could solve the problem of creating a distributed database of clients, or even of computing histograms on data in parallel, significantly more easily than more traditional programming paradigms.

toast0 7y ago
Rather than accessing the shared data directly, you send a message to the actor that owns that piece of shared data, that message could be a request for some data, or a request to modify it in some way. The actor that owns the data reads its mailbox of requests and processes them without worrying about locks and things, because it has exclusive access. The actor that needs to access the data doesn't worry about locks and things because it's not directly accessing it, it's just sending a message. The system worries about locks and things, because the message mailboxes are shared state to some extent. If you can cleanly separate ownership of different pieces of data into different actors, you get parallelism. If there's too much dependency between the pieces of data, so that separating ownership makes things more complex, maybe that becomes more visible.
- tsimionescu 7y ago
  That sounds nice, but it means that all reads and writes are serialized. You can't scale a system like this to, say, work for sign-up and retrieval of all Gmail users.
  - toast0 7y ago
    To scale up, you need to partition/shard the space. For gmail users, you could hash on the (normalized) username, and all users with hash between A and B would go to one actor, etc. You don't need (or want) parallelism for signup on a single user id, but you could hash or otherwise divide that work to that level. You can also do a partitioned work queue with a (smallish) worker pool per partition; and have the queue keep track of any keys with a current worker, to assign further work to that worker (to avoiding parallel work on the same key and the locking that requires)
    - tsimionescu 7y ago
      These are elegant solutions, but they are also rather complex, and I'm sure that if we dig in deeper there are further complexities to explore. I have no doubt that the actor model or continuations can be used to solve any problem. I do however doubt that it would turn out to be simpler than using shared state and explicit locking; or using ledger-like approaches. I also don't think it would be more complex! I believe that problems of distributed computing are inherently hard enough that the incidental complexity from your chosen modeling approach is not likely to be a significant portion of the overall complexity.
      - toast0 7y ago
        The nice thing, if you do it right, is that each piece is going to be simple. There may well be emergent complexity in how the simple parts go together, but that's going to happen anyway. Might as well make the parts simple where you can. Incidentally, I think email is a great example of something with clear divisions of work --- an actor could easily be responsible for a single user's mailbox, and there should be no overlap in responsibility. Possibly, you could have one actor per folder, but gmail doesn't really have folders, so...

eru 7y ago

Well, you will only have to worry about mutable global data if that's what your solution calls for. Essential complexity vs accidental.