3 ms·
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
by 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 agoYou 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 agoSetting 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 agoI 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.