4 ms·
Fowler's talk addressed issues arising from "mixing metaphors" by having both channels and Actors in our programming languages. The point of this post is to po
by carlehewitt 8y ago
Fowler's talk addressed issues arising from "mixing metaphors" by having both channels and Actors in our programming languages.
The point of this post is to point out that channels are best understood as Actors that take put and get messages thereby achieving a unification in our programming languages and conceptual framework.
Of course, a channel can be conceived as a "living entity" and an Actor can be used as a "transit mechanism."
- whalesalad 8y ago"Actors that take put and get messages" – makes sense.
- jchassoul 8y agoDo you want to abolish the protagonist role of the channel abstraction like in CSP based languages and certain message brokers? We can't have issues with channels if we're all actors and don't impedance mismatch the mixture when building our systems.
- carlehewitt 8y agoMessage passing communication is more fundamental than channel commutation. However, lists {T*] of type T are very important; especially when they are used with Futures.