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

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. [1] https://monkey.org/~marius/funsrv.pdf https://monkey.org/~marius/funsrv.pdf [2] https://www.techempower.com/benchmarks/#section=test&runid=9f738614-61d5-4c04-a1a5-3778b2ac3003 https://www.techempower.com/benchmarks/#section=test&runid=9...