4 ms·

Advanced Join Patterns for the Actor Model Based on CEP Techniques

84 points by mpweiher 6y ago

hazbo 6y ago
Footnote from page 3: > Elixir can be regarded as a modern Erlang (e.g., with macros) that runs atop BEAM; i.e.,the Erlang virtual machine. I've heard quite a few descriptions of Elixir, relative to Erlang, but I'm not quite sure about this one. Erlang has macros[0], though the syntax and general format does differ from that of Elixir's[1]. And though Erlang has been around since at least 1986, it has changed a lot in that time and is what I'd consider to be a modern programming language today, used at places such as WhatsApp, Grindr, Pintrest etc... [0]: https://erlang.org/doc/reference_manual/macros.html#defining-and-using-macros https://erlang.org/doc/reference_manual/macros.html#defining... [1]: https://elixir-lang.org/getting-started/meta/macros.html#our-first-macro https://elixir-lang.org/getting-started/meta/macros.html#our...
- pessimizer 6y ago
  I think a lot of people use "modern" to mean "doesn't look dated or unfamiliar to me." In programming language commentary, it generally means "looks like C or ALGOL."
Multicomp 6y ago
I wish we used the actor model more, it seems like it is a much better alternative to Green threads or semaphores or locks and mutexes for parallelism, and with Moore's law struggling to keep going, we can no longer continue to write our code AS synchronous code first, instead of async or parallel by default in my humble opinion. My understanding is that go routines in the golang language are pretty popular for parallelism there, and I at some point I'm going to be trying to use the language features of the language I'm currently using (F# mailbox processor) to put my money where my mouth is. but it continues to baffle me why we don't make fuller use of the multiprocessing capabilities of the processors we have today and the fortunes of RAM we have now, even taking into account that we are using higher level languages and not constantly profiling what we write for performance. Surely there must be a way to make writing parallel first code as natural to humans as our imperative code is today, right? Whether that be channels or actors or something else? Bonus: On a purely emotive level, anything with the name complex and technique in its name will have a rough time getting started with mind share in new users. If the goal is adoptionof languages that sport the features from this article, they may want to pick a less scary sounding name simply for pragmatic reasons.
- specialist 6y ago
  "better alternative to Green threads" Do you have opinions about Java's Project Loom? I'm a simple bear. I have always struggled with the architecture and organization of my async code. Stuff like exception handling, percolating errors up, rational back pressure and retry. My goal is to rewrite some of my server code using Project Loom, to see how it helps. "why we don't make fuller use of ... the fortunes of RAM we have now" I know you mention this as an aside, but I'd appreciate examples. I've been personally frustrated by teammates using external key/value stores for hot data sets which would trivially fit within RAM. But haven't had ready-made solutions. One recurring objection, for which I've had no good response, is how to quickly hoist (prime, seed, better term needed here) the RAM of new instances. Last time this came up, I helped come up with a compromise kludge using Redis. We added a local Redis instance to each web server, had the "master" create regular snapshots, copied that snapshot onto new EC2 instances during boot, used the snapshot to prime its local cache. It worked pretty good. Though I would have preferred in process, using Redis allowed better inspection and debugging, which was pretty cool. But devops wise, this Rube Goldberg kludge broke most teammate's brains. Thanks for listening. I keep looking to see if anyone's got a more turnkey solution.
  - an_opabinia 6y ago
    > Do you have opinions about Java's Project Loom? My experience with puniverse/quasar, Loom's predecessor, has been overall positive. There exists a whole actors framework built on top of it. The real problem is how clumsy it is to work with modern Futures code, you have to wrap everything.
  - lostcolony 6y ago
    "I've been personally frustrated by teammates using external key/value stores for hot data sets which would trivially fit within RAM. But haven't had ready-made solutions." You don't need a ready made solution unless you are trying to keep the data consistent, too. If you are, better to use something off the shelf. If you aren't...just deserialize it into whatever local data format makes sense, the same as you'd do reading from an external cache. You basically just have some push/poll mechanism to get data from your data store when updated/at intervals, deserialize it, and now it lives in RAM. The one downside of that is if autoscaling is thrashing instances, it can thrash your data store (though that's true with Redis etc too, depending what is loading data into it; having a caching layer in between DOES decouple that), and also what happens if the data store is unreachable (I've done things like query the rest of the cluster for the data, just via a REST API, because the total amount needed was all of a few megs).
vrnvu 6y ago
I find interesting their approach on how to compare the implementation complexity for the developer between the langauges. I quote, State management, "code that is used to save temporary data required by the ongoing coordination process" Windowing management, "code needed to discard messages that do not satisfy the pattern’s timing constraints" Sequencing control, "code to enforce a particular message order" Pattern definition, "ode used to express the type of messages to be synchronized and their content-based conditions" In their solution they free the programmer from most of these lines of code.
bicepjai 6y ago
Have anyone had experience with actor based models in Julia with libraries like signal, observables, rocket ?

84 points by mpweiher 6y ago

Footnote from page 3: > Elixir can be regarded as a modern Erlang (e.g., with macros) that runs atop BEAM; i.e.,the Erlang virtual machine. I've heard quite a few descriptions of Elixir, relative to Erlang, but I'm not quite sure about this one. Erlang has macros[0], though the syntax and general format does differ from that of Elixir's[1]. And though Erlang has been around since at least 1986, it has changed a lot in that time and is what I'd consider to be a modern programming language today, used at places such as WhatsApp, Grindr, Pintrest etc... [0]: https://erlang.org/doc/reference_manual/macros.html#defining-and-using-macros https://erlang.org/doc/reference_manual/macros.html#defining... [1]: https://elixir-lang.org/getting-started/meta/macros.html#our-first-macro https://elixir-lang.org/getting-started/meta/macros.html#our...

pessimizer 6y ago
I think a lot of people use "modern" to mean "doesn't look dated or unfamiliar to me." In programming language commentary, it generally means "looks like C or ALGOL."

Multicomp 6y ago

I wish we used the actor model more, it seems like it is a much better alternative to Green threads or semaphores or locks and mutexes for parallelism, and with Moore's law struggling to keep going, we can no longer continue to write our code AS synchronous code first, instead of async or parallel by default in my humble opinion. My understanding is that go routines in the golang language are pretty popular for parallelism there, and I at some point I'm going to be trying to use the language features of the language I'm currently using (F# mailbox processor) to put my money where my mouth is. but it continues to baffle me why we don't make fuller use of the multiprocessing capabilities of the processors we have today and the fortunes of RAM we have now, even taking into account that we are using higher level languages and not constantly profiling what we write for performance. Surely there must be a way to make writing parallel first code as natural to humans as our imperative code is today, right? Whether that be channels or actors or something else? Bonus: On a purely emotive level, anything with the name complex and technique in its name will have a rough time getting started with mind share in new users. If the goal is adoptionof languages that sport the features from this article, they may want to pick a less scary sounding name simply for pragmatic reasons.

specialist 6y ago
"better alternative to Green threads" Do you have opinions about Java's Project Loom? I'm a simple bear. I have always struggled with the architecture and organization of my async code. Stuff like exception handling, percolating errors up, rational back pressure and retry. My goal is to rewrite some of my server code using Project Loom, to see how it helps. "why we don't make fuller use of ... the fortunes of RAM we have now" I know you mention this as an aside, but I'd appreciate examples. I've been personally frustrated by teammates using external key/value stores for hot data sets which would trivially fit within RAM. But haven't had ready-made solutions. One recurring objection, for which I've had no good response, is how to quickly hoist (prime, seed, better term needed here) the RAM of new instances. Last time this came up, I helped come up with a compromise kludge using Redis. We added a local Redis instance to each web server, had the "master" create regular snapshots, copied that snapshot onto new EC2 instances during boot, used the snapshot to prime its local cache. It worked pretty good. Though I would have preferred in process, using Redis allowed better inspection and debugging, which was pretty cool. But devops wise, this Rube Goldberg kludge broke most teammate's brains. Thanks for listening. I keep looking to see if anyone's got a more turnkey solution.
- an_opabinia 6y ago
  > Do you have opinions about Java's Project Loom? My experience with puniverse/quasar, Loom's predecessor, has been overall positive. There exists a whole actors framework built on top of it. The real problem is how clumsy it is to work with modern Futures code, you have to wrap everything.
- lostcolony 6y ago
  "I've been personally frustrated by teammates using external key/value stores for hot data sets which would trivially fit within RAM. But haven't had ready-made solutions." You don't need a ready made solution unless you are trying to keep the data consistent, too. If you are, better to use something off the shelf. If you aren't...just deserialize it into whatever local data format makes sense, the same as you'd do reading from an external cache. You basically just have some push/poll mechanism to get data from your data store when updated/at intervals, deserialize it, and now it lives in RAM. The one downside of that is if autoscaling is thrashing instances, it can thrash your data store (though that's true with Redis etc too, depending what is loading data into it; having a caching layer in between DOES decouple that), and also what happens if the data store is unreachable (I've done things like query the rest of the cluster for the data, just via a REST API, because the total amount needed was all of a few megs).

vrnvu 6y ago

I find interesting their approach on how to compare the implementation complexity for the developer between the langauges. I quote, State management, "code that is used to save temporary data required by the ongoing coordination process" Windowing management, "code needed to discard messages that do not satisfy the pattern’s timing constraints" Sequencing control, "code to enforce a particular message order" Pattern definition, "ode used to express the type of messages to be synchronized and their content-based conditions" In their solution they free the programmer from most of these lines of code.

bicepjai 6y ago

Have anyone had experience with actor based models in Julia with libraries like signal, observables, rocket ?