3 ms·
When you look at how the composibility of Futures/Promises make both sideffecting and transformation tasks like monitoring completely trivial, it becomes really
by stuhood 11y ago
When you look at how the composibility of Futures/Promises make both sideffecting and transformation tasks like monitoring completely trivial, it becomes really hard to accept the actor model as a reasonable choice.
- felixgallo 11y agoWhat on earth? This is literally a post about the easy composability of the actor model.
- stuhood 11y agoThere is little-to-no actor composition in this post, except that which is hidden by the framework that they've implementated... instead, it describes using the methods of an interface to communicate between your implementation, and their framework. Composition of actors would allow for "wrapping" the actions of one actor in another and an implementation of RPC within your service itself (separate actors for both requests and responses), but that's not generally a thing you would do directly. Why? Because it's nontrivial, and you'd likely want a framework like theirs to orchestrate it.
- felixgallo 11y agoApparently you misunderstand all three of the original blog post, the actor model, and erlang's specific implementation. Composition of actors in the actor model is done by message proxying, just like this blog post does. The original actor's API is preserved and undergoes no semantic change, just like composition in any other functional concurrency paradigm. This works in erlang where it wouldn't work in most other languages because actors are very lightweight and message passing is a fast, optimized language primitive. Having written many hundreds of promises and awaits, and many thousands of actors, I'd have to say that the actor paradigm is far easier to scale and reason about than any promise or async/await implementation. That's partly because almost every other language is pretty terrible at concurrency. But your mileage may vary and everyone has their preferences.