I tried using actix for a recent project. I just could not get it to do what I wanted to. It always felt like a fight. I switched to rocket and everything is so much easier.
Everyone is saying great things about it, but I just want to point out that it's not for everyone.
Just to clarify for others, Actix is a more general actor-based programming framework. Actix-web is a nice little web server framework built on top of that, which you could integrate with other Actix components.
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.
I tried out actix-web and to be fair I'm not very fluent in Rust yet, so I had a similar experience of not being able to figure out some things readily enough.
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.
I had the opposite experience. I wrote an endpoint in 3 languages/frameworks last weekend: Java/Spring Boot, Elixir/Phoenix, and Rust/Rocket. (the last was mostly going off this blog post: https://lankydanblog.com/2018/05/20/creating-a-rusty-rocket-...) I was fighting with Rust Nightly failing to compile a couple different packages. All the GitHub issues seemed to point to finding the magical combination that would make things run. I gave up after an hour or so. I'd like to have something that runs on Rust Stable. Rocket was pretty cool _looking_ though.
I've done a simple hobby project in Rocket and ported to Actix.
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.
I also recently just finished porting a side project of my own from Rocket to Actix. I'm absolutely loving Actix so far!
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 think from ergonomics standpoint, actix is very close to rocket. of course rocket has some advantage, but actix compiles on stable and has zero codegen code. as soon as proc macro stabilizes both will be on par.
from performance perspective, actix is faster than rocket on any type of load.
I'm in the same boat, at least for actix-web. The static lifetimes on the handlers (and I think state) makes some things really painful, but is also part of the reason it gets the speed it does.
The actix library is fairly nice though, but still a few cases where the use of globals and/or statics introduces problems.
We've got some stuff in the pipeline that should relax that requirement. It plus async/await (which has a PR open in the compiler) should make all of this way easier.
Good to hear. Could use box to get around the static stuff, but given the power of lifetimes, would much rather be able to use lifetimes correctly to not have to box everything.
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.
When I started this, I considered writing it I rust. However, I really wanted this to be the tutorial I would have wanted to read several years ago when I first developed an interest in OS, and a "modern" system language like zig or rust would have hurt that goal.
What? No. Because way more people know C than rust. I wanted to be able to reach a wider audience. I know I would have looked elsewhere if I saw found this but I didn't know the language.
I do plan to implement paging. I already manage all of the physical pages, I just haven't enabled the mmu yet as I wanted to get more fun features in first
The extra information is all linked to from the main parts. The reason it's also on the main page is so anyone looking for that info independently of this particular tutorial might find it more easily.
Everyone is saying great things about it, but I just want to point out that it's not for everyone.