The naming is a little confusing here. This is Actix the actor model library, not "Actix web" the web framework that's usually discussed.<p>Originally "Actix web" depended on Actix the actor library, but no longer. Though they can be used together. And I think websockets still require actors?<p>I'm using both Actix and Actix web for a personal project. I like it a lot and think the actor model is good fit for applications that don't fit well into a request lifecycle.<p>My main pain point with it is the use of futures. Right now it's a huge pain to have more than one return value in an Actor Handler, the functions that handle actor messages. Even if you box the returned Future, you end up having to use futures::Either a bunch and when you mess it up you get tons of confusing errors filled with the huge inferred types.<p>Implementing something like:<p><pre><code> if (condition1) {
return <future for service call1>;
} else if (condition2) {
return <future for service call2>;
} else {
return <no-op future>;
}
</code></pre>
Is a big pain requiring two layers of future::Either. Or I just don't know what I'm doing, which is very possible.<p>async/await would be a huge improvement, but can't be used at the moment, even though the current version of Actix uses std::future's.
What is the difference between the actor model and object oriented programming? It seems to me like they are basically the same paradigm but with all the names changed, and some additional restrictions like all messages being async and objects only being able to process one message at a time. Why is it necessary to create a whole new paradigm just to enforce such a style?
Highly recommend Bastion if you're looking for a Rust Actor library / runtime. It uses async/await etc, and has supervision trees and restart strategies taken straight from Erlang/OTP<p><a href="https://docs.rs/bastion/0.3.4/bastion/" rel="nofollow">https://docs.rs/bastion/0.3.4/bastion/</a><p><a href="https://github.com/bastion-rs/bastion" rel="nofollow">https://github.com/bastion-rs/bastion</a>
I'm amazed on how much discussion digressed to actix-web. Understandable, seen the latest happenings there, but still... I tried quite a while ago Actix, coming from Erlang/Elixir and Scala/Akka. While the cognitive load of using it was not high, when I started my first test, I noticed one core being maxed out, and all others sleeping, which was kinda unusual for me. I asked why, and the author answered that it uses an event loop, so if you want it otherwise, go away and use something else, like Riker... So I went away :) ... I would assume this kind of behaviour has been corrected meanwhile (I mean the library, not the comms), because otherway, it's just a Node written in Rust. My 2c :)
Actix (the actor framework) is separate from what people are discussing here: actix-web, which <i>supports</i> actix). In earlier versions of actix-web it was based around actix; I remember implementing actors and handlers. Since 1.0 or so that got changed to more of a standard setup.<p>I’ll add my 2c on actix-web: in my opinion it tries to do too much. hyper (simply based on tokio) is all you need for a fast async server. Anecdotally, I know many people who basically use just this stack, over actix-web/warp/tower etc.<p>There are other actor systems, like kay [0].<p>[0]: <a href="https://citybound.github.io/citybound/kay/index.html" rel="nofollow">https://citybound.github.io/citybound/kay/index.html</a>
I'm currently in the process of removing actix from one of my projects and replacing it with asyc/await and some channels. Actix comes with a ton of dependencies and doesn't buy you a whole lot anymore.
Can somebody please summarize the outcome of the recent kerfuffle? I don't mind which way it came out, but it seems worth knowing what it was.<p>I absolutely don't want any even-slightly-inflammatory answer.
I’m really excited about this project. Using Akka was one of those things that made distributed/parallel execution just “click”. Particularly useful was being able to draw your architecture the same way one might draw an organization on a whiteboard. Everyone can quickly understand what happens and who is responsible for what.
Out of curiosity - actix seems to be very performant compared to actor frameworks implemented in other languages - would it be a good fit to implement a database using it?
For example mapping worker pool and workers to actors?
Actors in principle (isolated objects assigned to threads) sound great until you need to SHARE data, then you enter a new universe of compromises where you need locking mechanisms (for performance), but no language semantics support it natively. Pony introduced reference capabilities but that still created a cludge for those times you needed synchronous access. There is no model yet where locking primitives are associated with resource handles.
Whats the state of Rust if I wanted to get into it for backend development? I've looked briefly into Rocket and liked it but didn't delve too deep, I understand Actix is one of the most mature?
This framework's core developer has left, probably new community took it over. Hopefully it will continue to be supported and developed.<p>Rust still has a way to go for being a mature eco-system for doing any serious web programming work. Given the focus of Rust on systems programming, I will still be careful to consider it for anything web related.<p>Hopefully situations like abandoning a project suddenly will not happen again. [1] [2]<p>[1] <a href="https://words.steveklabnik.com/a-sad-day-for-rust" rel="nofollow">https://words.steveklabnik.com/a-sad-day-for-rust</a><p>[2] <a href="https://github.com/actix/actix-web/issues/1289" rel="nofollow">https://github.com/actix/actix-web/issues/1289</a>