so, don't use actors when you don't have a state, and the 'demo' shows prime number search :) anyway, good talk.
@rahulpyd1
8 жыл бұрын
Good talk.
@w108dab1
7 жыл бұрын
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.
@Farrukhobaid
7 жыл бұрын
excellent presentation
@timmark4190
6 жыл бұрын
@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
@johnmurray909
6 жыл бұрын
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).
@drakezen
8 жыл бұрын
Great explanation.
@w108dab1
7 жыл бұрын
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.
@AdrianSmithRocks
6 жыл бұрын
Brilliant talk
@UliTroyo
7 жыл бұрын
Great talk!
@w108dab1
7 жыл бұрын
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.
@johnmurray909
6 жыл бұрын
@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.
Пікірлер: 13