Reactors, Channels, and Event Streams for Composable Distributed Programming | Hacker News Reader

Reactors, Channels, and Event Streams for Composable Distributed Programming

researchgate.net

83 pointsacjohnson558 comments

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 - "GenStage is a specification for exchanging events between producers and consumers."

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

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.

"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

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

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.

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

Alternative source for the paper: http://axel22.github.io/resources/docs/reactors.pdf

Isn't this just ReactiveX?

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.

Reply on news.ycombinator.com