Re:Tokio 1.0 – async runtime for Rust
by pvorb on Wednesday December 23, 2020 @06:14PM
(#25523386)
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.
[ Parent
| on HN ]
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.
Re:Tokio 1.0 – async runtime for Rust
by da39a3ee on Thursday December 24, 2020 @02:13AM
(#25525629)
> 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.
Re:Tokio 1.0 – async runtime for Rust
by lallysingh on Wednesday December 23, 2020 @11:56PM
(#25525160)
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.