5 ms·

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

pvorb 6y ago
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.
- pvorb 6y ago
  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.
  - nchi3 6y ago
    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.
    - pvorb 6y ago
      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.
    - lallysingh 6y ago
      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.
      - nchi3 6y ago
        > 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.
    - da39a3ee 6y ago
      > 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-asyncio/ https://lucumr.pocoo.org/2016/10/30/i-dont-understand-asynci...
      - nchi3 6y ago
        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.
- nicoburns 6y ago
  Alternatively use async everywhere from the start and your headaches go away too. It's mixing blocking code with async code that causes issues.
  - pvorb 6y ago
    Just do it if everyone in your team is comfortable with it. I'm just not as productive with async code.
    - nicoburns 6y ago
      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.
  - lumost 6y ago
    won't this just bifurcate the rust ecosystem between async and non-async rust libraries?
    - loeg 6y ago
      It's already there.
- nemothekid 6y ago
  >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.
- sagichmal 6y ago
  You underestimate how common this use case is. It motivates the Go language, which is much more widely used than Rust.
platinumrad 6y ago
Any web application will already be "holding back" Nginx because Nginx doesn't have to do things like database queries...

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.

pvorb 6y ago
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.
- nchi3 6y ago
  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.
  - pvorb 6y ago
    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.
  - lallysingh 6y ago
    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.
    - nchi3 6y ago
      > 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.
  - da39a3ee 6y ago
    > 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-asyncio/ https://lucumr.pocoo.org/2016/10/30/i-dont-understand-asynci...
    - nchi3 6y ago
      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.
nicoburns 6y ago
Alternatively use async everywhere from the start and your headaches go away too. It's mixing blocking code with async code that causes issues.
- pvorb 6y ago
  Just do it if everyone in your team is comfortable with it. I'm just not as productive with async code.
  - nicoburns 6y ago
    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.
- lumost 6y ago
  won't this just bifurcate the rust ecosystem between async and non-async rust libraries?
  - loeg 6y ago
    It's already there.
nemothekid 6y ago
>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.
sagichmal 6y ago
You underestimate how common this use case is. It motivates the Go language, which is much more widely used than Rust.

platinumrad 6y ago

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