@22 you mentioned the actor would respond back to the http. How does one do that? How does an actor after processing go back to same thread that made the call
Hi Tim! It really depends on the language/framework/etc. All you need, at the lowest level, is the socket handle, which can be used from any thread. It's likely however that you are using a web-framework or HTTP library, so I can't speak to the specifics of every library. If you are working with a web-framework that assumes synchronous requests, then you might have trouble. If you have a framework that supports Futures/Promises as result-objects, then you can tie those to Actor request/responses rather easily. I'd also add that if you are considering adopting the actor-model in one of your projects, I recommend embracing the abstraction and avoiding use of thread-specific-utilities (e.g. ThreadLocal on the JVM).
Then why do people hated the actor-models so much when it can solve so many problems. I have used actor modeling myself for a project that would have failed otherwise.
Then why do people hated the actor-models so much when it can solve so many problems. I have used actor modeling myself for a project that would have failed otherwise.
Then why do people hated the actor-models so much when it can solve so many problems?? I have used actor modeling myself for a project that would have failed otherwise.
@w108dab1 In my experience in talking with people about the Actor Model, it seems concerns center around 1) tooling and 2) bringing a team up to speed on a new paradigm. 2 is doable with time, patience, and lots of hands-on help/guidance. 1 is a tougher nugget to crack. Depending on your chosen actor framework/language, varying levels of tooling support will be available. In general, though, I have yet to see comprehensive tooling for any framework. This usually requires building a lot of in-house tools, which can be an expensive endeavor. However, even with both of these concerns, I feel like the major roadblock to more people adopting the Actor Model is not understanding the value-proposition. For a given problem, what makes actors a better choice over threading, eventing, futures/promises, etc. If the trade-offs are better understood, then more informed decisions can be made. Of course there will always be companies/groups that will stick to skills already possessed by most of the team rather than adopt/learn something new.
![[안방1열 풀캠4K] 베이비몬스터 'DRIP' (BABYMONSTER FullCam)│@SBS Inkigayo 241110](http://i.ytimg.com/vi/AQ4RIghEvUs/mqdefault.jpg)
so, don't use actors when you don't have a state, and the 'demo' shows prime number search :) anyway, good talk.
@22 you mentioned the actor would respond back to the http. How does one do that? How does an actor after processing go back to same thread that made the call
Hi Tim! It really depends on the language/framework/etc. All you need, at the lowest level, is the socket handle, which can be used from any thread. It's likely however that you are using a web-framework or HTTP library, so I can't speak to the specifics of every library. If you are working with a web-framework that assumes synchronous requests, then you might have trouble. If you have a framework that supports Futures/Promises as result-objects, then you can tie those to Actor request/responses rather easily. I'd also add that if you are considering adopting the actor-model in one of your projects, I recommend embracing the abstraction and avoiding use of thread-specific-utilities (e.g. ThreadLocal on the JVM).
excellent presentation
Great explanation.
Then why do people hated the actor-models so much when it can solve so many problems. I have used actor modeling myself for a project that would have failed otherwise.
Good talk.
Then why do people hated the actor-models so much when it can solve so many problems. I have used actor modeling myself for a project that would have failed otherwise.
Brilliant talk
Great talk!
Then why do people hated the actor-models so much when it can solve so many problems?? I have used actor modeling myself for a project that would have failed otherwise.
@w108dab1 In my experience in talking with people about the Actor Model, it seems concerns center around 1) tooling and 2) bringing a team up to speed on a new paradigm. 2 is doable with time, patience, and lots of hands-on help/guidance. 1 is a tougher nugget to crack. Depending on your chosen actor framework/language, varying levels of tooling support will be available. In general, though, I have yet to see comprehensive tooling for any framework. This usually requires building a lot of in-house tools, which can be an expensive endeavor.
However, even with both of these concerns, I feel like the major roadblock to more people adopting the Actor Model is not understanding the value-proposition. For a given problem, what makes actors a better choice over threading, eventing, futures/promises, etc. If the trade-offs are better understood, then more informed decisions can be made. Of course there will always be companies/groups that will stick to skills already possessed by most of the team rather than adopt/learn something new.
right