Introduction to the Actor Model for Concurrent Computation: Tech Talks @ AppNexus 

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.

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.

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).