
Reactors, Channels, and Event Streams for Composable Distributed Programming - acjohnson55
https://www.researchgate.net/publication/290195429_Reactors_Channels_and_Event_Streams_for_Composable_Distributed_Programming
======
geonnave
I didn't read the paper yet, but this thing of "composable distributed
processing" made me think of Elixir's `GenStage`[0], which is still in
development.

Another thing, that is indeed linked on GenStage's page as a reference, is
Lasp language [1].

If anyone knows more about this stuff, and could say if these cited things are
even related, it would be cool to hear.

[0] [https://github.com/elixir-lang/gen_stage](https://github.com/elixir-
lang/gen_stage) \- "GenStage is a specification for exchanging events between
producers and consumers."

[1] [https://lasp-lang.org/](https://lasp-lang.org/)

------
weq
im working on a c# micro-framework based on Rx/ES that has a reactor as its
primitive. slightly different but similiar to the thoughts outlined in the
article, nice to know im not the only one thinking at a higher level then the
actor. the reactors in my world are have composable IO streams, and can be
chained together or with eventmanagers which have backing channels that could
be implemented with queues or integrated with akka. in my world though,
reactors have child services which do the actual state modification. event
processors/pulsers/publishers are the service primitives. i personally though
dont want to limit this stuff to the server, and am designing it into the UI
using the same API aka what the JS calls call flux.

------
kristianp
"Reactors, proposed in this paper"

I take it they're proposing something different to the reactor pattern [1],
since this seems to have been published in 2015 [2]? Sorry, I haven't read the
paper yet.

[1]
[https://en.wikipedia.org/wiki/Reactor_pattern](https://en.wikipedia.org/wiki/Reactor_pattern)

[2]
[https://axel22.github.io/home/professional/](https://axel22.github.io/home/professional/)

~~~
chandler21
It's different from the reactor pattern. They raise the concept of an event
stream to the first level, which is then used to compose message protocols.

------
acjohnson55
I'm still reading the paper, but I'm finding it more difficult to understand
than Akka actors, at least as it's discussed in the paper. The protocols hurt
my brain a bit. But I do really dig the type-safety compared to regular Akka
actors. I wonder if this could end up replacing Akka Typed [1].

[1]
[http://doc.akka.io/docs/akka/current/scala/typed.html](http://doc.akka.io/docs/akka/current/scala/typed.html)

------
paulajohnson
Alternative source for the paper:
[http://axel22.github.io/resources/docs/reactors.pdf](http://axel22.github.io/resources/docs/reactors.pdf)

------
sktrdie
Isn't this just ReactiveX?

~~~
noelwelsh
I think the intra-reactor communication is analogous to ReactiveX, but not the
inter-reactor communication.

ReactiveX doesn't typically model bidirectional information flow (call /
response) so it's not applicable to all the problems one has in distributed
systems.

