Most people are not writing the next nginx. They are writing web application servers behind nginx.

This, merely, means that the web application code will hold back what Nginx is capable of serving.

If you know that there will be 10k concurrent users in your application, go ahead and use async right from the start.

But for the rest of us, simple, blocking code will do just fine and save us a few headaches.

Alternatively use async everywhere from the start and your headaches go away too. It's mixing blocking code with async code that causes issues.

Just do it if everyone in your team is comfortable with it. I'm just not as productive with async code.

Ah yeah, as someone whose first langauge is javascript where all IO and even things like timers are async, I forget that not everyone groks it. It's really not that complicated (at work we have junior devs with 6 months experience writing async code no problem), but I think there is a certain amount of unlearning that needs to be done if you're used to working with threaded code.

won't this just bifurcate the rust ecosystem between async and non-async rust libraries?

It's already there.

You underestimate how common this use case is. It motivates the Go language, which is much more widely used than Rust.

>But for the rest of us, simple, blocking code will do just fine and save us a few headaches.

I understand your point, but if performance isn't a concern, why use Rust at all? If the intricacies of async is that much of a burden then Rust is probably not the right tool of the job.

And once you get to a limit, the alternative to rewriting everything in non-blocking code might be to put multiple instances of your blocking app on multiple VMs/k8s/whatever behind a load balancer.

Or, you just take the initial leap and write async from the start. For languages with decent abstractions such as async/await, it really isn't hard when you've done it for a while, and I'd make the same argument as one of the parent posters in that it's great "documentation".

K8s is brings way more complexity and headache, so it's kind of funny that you suggest that before using async/await.

> For languages with decent abstractions such as async/await, it really isn't hard when you've done it for a while

https://lucumr.pocoo.org/2016/10/30/i-dont-understand-asynci...

I haven't used async in Python, but I'd bet you don't really _need_ to understand every single one of those concepts, unless you're developing something very niche and low level (or an interpreter). If you do need to know it, I'd argue that it's not a great abstraction; you definitely don't need to know that implementation details and concepts in either C# or Rust to use async/await.

Setting up k8s once solves the problem for all your apps. In contrast, the additional software complexity of async/await is duplicated across all of them.

If your planning to scale up, k8s is likely something you'll want later. Additional complexity in your apps is not.

> Additional complexity in your apps is not.

My point was that it really isn't that much additional complexity. 99.9% of the time, the main difference is that you'll have to write "await". You don't really need to know that there's a state machine hiding beneath.

You probably shouldn't introduce K8s just to solve that problem. I'm just saying if you're already on k8s, scaling horizontally becomes easy.

Any web application will already be "holding back" Nginx because Nginx doesn't have to do things like database queries...

Maybe in your world!