I'm using actix-web in my work and am familiar with the project, so I'll try to summarize for everyone why this 1.0 release is so significant.
This is a major milestone for the entire Rust community because we now have the first web framework written in stable Rust with an architecture that a credible author has deemed worthy of maintaining backwards compatibility for and a code base mature enough to have earned a 1.0 designation. This is real progress.
The architecture of actix-web 1.0 is very different from that of 0.7. In many respects, it was a rewrite that began last Summer. The architecture is no longer based on an actor paradigm but rather one of Services, largely inspired by Eriksen et al's finagle work [1] adopted at Twitter. This service architecture is accessible through a library known as actix-net. Essentially, actix-web is a web-based actix-net server. If actix-web were bitcoin, actix-net would be its blockchain. Because of this, actix-net may be even more significant to the broader Rust community. The actor models can still be imported and used but no longer act as the default mechanisms driving the server.
Regarding performance, according to the Tech Empower benchmarks that evaluate hundreds of web frameworks across all major languages, actix-web is top-ranking [2] and first in a few benches. The last benchmark represents a beta version of actix-web from last month and results may have slightly improved with 1.0. actix-web is very modular, allowing programmers to only use what is needed and no more.
In terms of usability, actix-web 1.0 api is far easier to approach than 0.7. Running blocking calls against a database effortlessly flows within combinators now where as before one had to implement a lot of SyncActor boilerplate. Endpoint resource registration can now either be explicitly registered within an App instance or with a new set of proc macros, but routes still need to be registered manually. The new testing api is far easier to work with for unit or integration tests.
A single person wrote two very different platforms in order to get to where it is today. I believe that future progress requires community participation at all levels. This is a great time for system programmers to take a deep dive and learn, from the network-level up, how to build a high-performing, flexible server. Write about it. Talk about it at meetups and conferences. Pay forward.
Thanks, Nikolay, for your hard work and sacrifice.
Does this mean that actix-web does not use actix (the actor system library) anymore? If so, is there any cause of concern regarding the maintenance and state of actix going forward? I think it's a very important library and would hate to see it abandoned. If anything, it needs more love, particularly regarding documentation.
I'm also interested in any alternatives for implementing an actor-based application in Rust, if any.
That is correct: the actor library is no longer used by default, although it can be imported and used in one's own server. The best part about using Rust is that it has shown to have a very good shelf life when a project reaches maintenance mode -- see the iron web framework as an example.
If the actix library suits your needs, why look elsewhere? Develop expertise and maintain it. If another actor project exists, the same risk of continuity applies.
The actix library is good, but as I mentioned the documentation is pretty lacking. Also it's changing very fast and the little info you can find on how to achieve certain things on e.g. reddit or StackOverflow is mostly obsolete now. Those are the only reasons why I'd be interested in seeing alternatives (if any exist, which is doubtful).
How can you be at the same time concerned by the fact “it's changing very fast” and having “concern regarding the maintenance and state of actix going forward” ?
Now that Actix isn't used in Actix-web anymore, I would expect two alternatives: it either continues to be developed at a fast pace (with frequent breaking changes) or it will settle it in current state, due to the lack of interest from its main author (with possible maintenance concerns, but with no more breaking changes). But I don't see how both could happen at the same time…
I don't have concerns regarding it changing very fast―it's often good for a novel library in a language (and an actors library for Rust qualifies as that) to iterate on the public APIs and experiment a bit to make the library better. I was just saying that to explain my grievances with the docs. Good experience for users is usually either a very well documented library which may then change quickly, or a not-that-well-documented library that has a stable interface so third-party info on how to use it does not get out of date quickly. Both of those together can create trouble. It did for me―Actix was so far the former, which is not ideal, but the latter would also be a pity if said stabilization happened because of abandonment, not out of convergence on a 1.0-worthy API.
Not OP but to answer #2, based on the benchmark code here [1] the difference is that actix-pg accesses the database through message passing in the actor system [2] while actix-core accesses it directly [3].
I'm glad there's finally a reasonable framework that isn't on Nightly. That was the biggest "Yeah I'll just wait" moment for me with respect to Rust and web stuff.
I somewhat share your feelings here... I'm particularly interested in seeing what comes out of normalizing async/await later in the summer, and how that progresses.
Actix completely changed my relationship to writing Async code in Rust, which I had really struggled with for a long time. I'm a huge fan and it definitely feels like a first step in more mature tooling for web services in Rust.
There is only one option: diesel [1]. It is a powerful solution for correctness, as it is completely type-safe. It's also really fast since a lot of work is delegated to compile time.
There are also plenty of drawbacks though: the extensive type system hacking can lead to very confusing compiler errors, it doesn't work well when you need to sometimes fall back to more dynamic db handling, and it doesn't handle large tables well. (very long compile times etc), and the documentation is quite sparse.
It's a robust solution for greenfield projects where you can design the schema partially with diesel in mind, but I wouldn't recommend it for existing DBs or projects that you know will grow large (eg 100+ column tables etc).
Fun fact: The amount of traits implementations that need to be generated to support tables with 128 columns actually makes diesel an interest benchmark of the Rust compiler.
The main ORM in the ecosystem is Diesel[0], which is very usable, though it can be a bit hard to get into due to lack of documentation/tutorials (compared to what people are used to from other ORMs).
It has to be said though, that compared to other ecosystems, less focus is put on ORMs, and more focus is put on the specific database crates (e.g. rust-postgres), and how to make them easy to use without ORMs.
thanks for the great rundown, is there a good complete example you could reccomend that shows off 1.0 features that includes web sockets. I Would like to try and Actix up and this seems like a good time (since last time I tried I found the Actor model a little confusing).
It appears this example I found is a little dated (using .8 and actors).
This is a major milestone for the entire Rust community because we now have the first web framework written in stable Rust with an architecture that a credible author has deemed worthy of maintaining backwards compatibility for and a code base mature enough to have earned a 1.0 designation. This is real progress.
The architecture of actix-web 1.0 is very different from that of 0.7. In many respects, it was a rewrite that began last Summer. The architecture is no longer based on an actor paradigm but rather one of Services, largely inspired by Eriksen et al's finagle work [1] adopted at Twitter. This service architecture is accessible through a library known as actix-net. Essentially, actix-web is a web-based actix-net server. If actix-web were bitcoin, actix-net would be its blockchain. Because of this, actix-net may be even more significant to the broader Rust community. The actor models can still be imported and used but no longer act as the default mechanisms driving the server.
Regarding performance, according to the Tech Empower benchmarks that evaluate hundreds of web frameworks across all major languages, actix-web is top-ranking [2] and first in a few benches. The last benchmark represents a beta version of actix-web from last month and results may have slightly improved with 1.0. actix-web is very modular, allowing programmers to only use what is needed and no more.
In terms of usability, actix-web 1.0 api is far easier to approach than 0.7. Running blocking calls against a database effortlessly flows within combinators now where as before one had to implement a lot of SyncActor boilerplate. Endpoint resource registration can now either be explicitly registered within an App instance or with a new set of proc macros, but routes still need to be registered manually. The new testing api is far easier to work with for unit or integration tests.
A single person wrote two very different platforms in order to get to where it is today. I believe that future progress requires community participation at all levels. This is a great time for system programmers to take a deep dive and learn, from the network-level up, how to build a high-performing, flexible server. Write about it. Talk about it at meetups and conferences. Pay forward.
Thanks, Nikolay, for your hard work and sacrifice.
[1] https://monkey.org/~marius/funsrv.pdf
[2] https://www.techempower.com/benchmarks/#section=test&runid=9...