3 ms·

> 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. Seem

> 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).

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).