4 ms·

Nitpick: Actors or goroutines or async are mostly used to deal with concurrency. CUDA & friends are used for parallelism. The paper: The motivation is a proble

Nitpick: Actors or goroutines or async are mostly used to deal with concurrency. CUDA & friends are used for parallelism. The paper: The motivation is a problem suitable to be solved via rule systems. It's a bit unclear why the rule system needs to be grafted on top of an actor model. Actors: Programming with async messages is hard. Message ordering matters, no clear error reporting, no stack traces, distributed state. This is hardware hard, as in bring in formal verification methods hard. To be avoided in favor of a centralized coordinator solution if at all possible. I wonder if, alternatively, one could use Rx processing over the stream of events. Motivating example from the paper: 1. Turn on the lights in a room if someone enters, and the ambient light is less than 40lux. 2. Turn off the lights in a room after two minutes without detecting any movement. 3. Send a notification when a window has been open for over an hour. 4. Send a notification if someone presses the doorbell, but only if no notification was already sent in the past 30 seconds. 5. Detect home arrival or leaving based on a particular sequence of messages, and activate the corresponding scene. 6. Send a notification if the combined electricity consumption of the past three weeks is greater than 200 kWh. 7. Send a notification if the boiler fires three Floor Heating Failures and one InternalFailure within the past hour, but only if no notification was sent in the past hour.

an_opabinia 6y ago
> The motivation is a problem suitable to be solved via rule systems > I wonder if, alternatively, one could use Rx processing over the stream of events. Seems like the right solution, and additionally doesn't need to be centralized, strictly speaking - you can ship the code for Rx operations anywhere. > Message ordering matters, no clear error reporting, no stack traces, distributed state It's funny. For all the useless Java "factory" patterns, the one thing there ISN'T a factory for - Futures - is the one thing you could use to easily solve your list of issues and really improve the quality of actor / async programming. This is fundamentally what NewRelic and other instrumenting libraries do though, also there's stuff like JetBrain's `Schedule` and `Execute`. It's a bit of a puzzle to me why this isn't just standardized.
- JD557 6y ago
  >It's funny. For all the useless Java "factory" patterns, the one thing there ISN'T a factory for - Futures[...]. >It's a bit of a puzzle to me why this isn't just standardized. It kind of is. A `FutureFactory` it's pretty much `IO` (as in, Haskell's IO). It just so happens that a lot of implementations don't want you to call `unsafeRun` (so that `unsafeRun` in only called at the edge of the world) and some implemetations don't like, but nothing stops you from having a `unsafeRunToFuture` that returns a `Future`. This is actually pretty common in Scala. Some examples: - Cats-effect: https://typelevel.org/cats-effect/datatypes/io.html#unsafetofuture https://typelevel.org/cats-effect/datatypes/io.html#unsafeto... - ZIO: https://javadoc.io/doc/dev.zio/zio_2.12/latest/zio/Runtime.html#unsafeRunToFuture[E%3C:Throwable,A](zio:zio.ZIO[R,E,A]):zio.CancelableFuture[A] https://javadoc.io/doc/dev.zio/zio_2.12/latest/zio/Runtime.h... - Monix: https://monix.io/api/current/monix/eval/Task.html#runToFuture(implicits:monix.execution.Scheduler):monix.execution.CancelableFuture[A] https://monix.io/api/current/monix/eval/Task.html#runToFutur... I guess that this is not very standardized in OOP languages because they lack some of the ergonomics to use such factories (namely, do-notation).

an_opabinia 6y ago

> The motivation is a problem suitable to be solved via rule systems > I wonder if, alternatively, one could use Rx processing over the stream of events. Seems like the right solution, and additionally doesn't need to be centralized, strictly speaking - you can ship the code for Rx operations anywhere. > Message ordering matters, no clear error reporting, no stack traces, distributed state It's funny. For all the useless Java "factory" patterns, the one thing there ISN'T a factory for - Futures - is the one thing you could use to easily solve your list of issues and really improve the quality of actor / async programming. This is fundamentally what NewRelic and other instrumenting libraries do though, also there's stuff like JetBrain's `Schedule` and `Execute`. It's a bit of a puzzle to me why this isn't just standardized.

JD557 6y ago
>It's funny. For all the useless Java "factory" patterns, the one thing there ISN'T a factory for - Futures[...]. >It's a bit of a puzzle to me why this isn't just standardized. It kind of is. A `FutureFactory` it's pretty much `IO` (as in, Haskell's IO). It just so happens that a lot of implementations don't want you to call `unsafeRun` (so that `unsafeRun` in only called at the edge of the world) and some implemetations don't like, but nothing stops you from having a `unsafeRunToFuture` that returns a `Future`. This is actually pretty common in Scala. Some examples: - Cats-effect: https://typelevel.org/cats-effect/datatypes/io.html#unsafetofuture https://typelevel.org/cats-effect/datatypes/io.html#unsafeto... - ZIO: https://javadoc.io/doc/dev.zio/zio_2.12/latest/zio/Runtime.html#unsafeRunToFuture[E%3C:Throwable,A](zio:zio.ZIO[R,E,A]):zio.CancelableFuture[A] https://javadoc.io/doc/dev.zio/zio_2.12/latest/zio/Runtime.h... - Monix: https://monix.io/api/current/monix/eval/Task.html#runToFuture(implicits:monix.execution.Scheduler):monix.execution.CancelableFuture[A] https://monix.io/api/current/monix/eval/Task.html#runToFutur... I guess that this is not very standardized in OOP languages because they lack some of the ergonomics to use such factories (namely, do-notation).