Oddbean

▲ ▼

 @bf55f1f1 One could create a new web framework that is synchronous which offers trivial parallelization (launch multiple instances). But how do you share state then without a database? A required database increases the complexity.
And what about performance? Such a framework would not have the same performance like Axum. Who would use it then?

▲ ▼

 @bf55f1f1 If such a framework is targeted to newcomers, do you think many newcomers try Rust because of its reliability etc? I don't think so. I think that many of them, especially in the web ecosystem, come for the performance and low resource consumption. I would guess that most of them already have experience in Node, Python and Ruby. They know a slow solution. Why would they use that framework?

▲ ▼

 @bf55f1f1 So I guess that only people would use it who are already familiar with Rust and convinced by it and they want to build a backend. But then, if they are already sold on Rust, wouldn't they just learn async?
The route for newcomers before they can work with Axum and SQLx is longer than other routes which don't include async. But for people who are familiar with Rust, it is just one step: Learning async. And I think that we currently have a problem of documentation here as you mentioned.

▲ ▼

 @bf55f1f1 My conclusion would be:
- Improve the documentation of async
- Make this difficulty levels clear to newcomers to climb up step by step: sync single threaded < sync multithreaded < async single threaded < async multithreaded
- Stabalize missing async features like async traits (work in progress)
- Try to reach having libraries agnostic regarding the async runtime (lowest priority for me personally since we have Tokio)