Everyone is saying great things about it, but I just want to point out that it's not for everyone.
From looking at the two, Actix is more minimalist with direct control, though it has some nice middleware built in. Rocket is a more Rails-like “everything works and is magic” approach. Both seem like they could be great but it depends on your use case.
So as a result I've opted to using D instead for my current project, I've been able to get more figured out with Vibe.d in shorter time so I'll likely stick to D for this project due to time being a factor against me.
Actix-web was almost a drop-in replacement.
Anyone have any insight into how Actix and Rocket compare? I'm interested mostly in ergonomics and safety.
from performance perspective, actix is faster than rocket on any type of load.
I'm not experienced with web services and my project was very limited for learning purposes, here my take away:
I like both and for me Rocket was way more ergonomic for creating routes dealing as if they're simple functions where input and output are dealt automatically with (from request and to response).
Actix advantage is actors and is easy to be fully async, I had some issues dealing with it but most of my troubles were extracting request data and building responses.
When actix-web will support magic as Rocket (once proc-macros becomes stable) then actix-web will have the edge if Rocket don't become async-ready and stable before.
For both it is only question of missing stable rust features and actix-web is already running on stable.
actix-web: - easy - async - stable
Rocket: - stupidly easy - sync - nightly
Other than Rocket being nightly, the other reason I switched to Actix was because Rocket doesn't have the ability to respond to requests directly within the middleware layer, you can only modify the response but not return early. This is pretty important with regards to CORS and trying to catch all OPTIONS requests. There are a few solutions of course, but all of them felt hacky or verbose.
I have no complaints with Actix yet.
The actix library is fairly nice though, but still a few cases where the use of globals and/or statics introduces problems.
One other thing that wasn't really apparent but would have made my life easier is a way to use an actor to handle a request, so I could have access to a context for thread related activities (e.g. tokio handles). It feels wrong to just use Arbiter::handle there, especially for testable code.