Async infrastructure allows your stuff to be sync or async. While sync infrastructure forces your stuff to be sync.
If anything sync (not async) infects everything you do.
Of course it depends if you call the infrastructure (then it's better for it to be sync) of if the infrastructure calls you (then it's better to be async).
Rendering engine is something you rarely call, but it often calls your functions.
Yes, and that’s the worst part of async. That’s why you need to be very strategic about where you introduce it into your code in order to minimize the number of functions it infects, not give up and write a framework that’s all async for no good reason.
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
Yes. But you should be equally strategic about introducing sync code into your platform. Because making your platform sync basically makes it only be able to call sync functions of your code.
It's not that async infects. It's sync that infects and restricts. We are just used to it by default.
The fact that we started from sync was the cause of all the trouble of rpc because everything outside of CPU is innately async.
So make your utility functions sync whenever you can but make your platforms and frameworks async.
I just completely disagree. Async is syntactic sugar that can be reduced to sync code with callbacks. It doesn’t exist on equal footing. If you want to call sync code from async code, you just… call it. If it performs blocking IO, it’ll block, but that’s exactly what it would do if called from other sync code, too.
By contrast, calling async code from sync code requires a special blocking wrapper (Python) or unavoidably breaks control flow (JavaScript).
> Async is syntactic sugar that can be reduced to sync code with callbacks
The whole point of introducing async was to get away from callback hell.
> By contrast, calling async code from sync code requires a special blocking wrapper (Python) ...
That's exaclty my point. If you don't have async by default in your platform you need to do stupid things to fake it. If function calls and main in Python were innately async you could be calling async code just as easily as sync code.
> [...] or unavoidably breaks control flow (JavaScript).
async/await syntax avoids it completely.
Tbh await should be default function call semantics and there should be special keyword for calling without awaiting. But since we come from sync primitives that would require small revolution that might happen at some point.
> Async is syntactic sugar
You could make sync code be syntactic sugar for await.
> would require small revolution that might happen at some point.
or python could have blessed gevent and done away with all the nonsense.
I hope that someone does an oral history of why gevent wasn't seen as the solution here. The existence of models like Twisted, and a general idea that yields to an event thread should be explicit in some way, I think caused the exact kind of fracturing of the ecosystem that everyone was trying to avoid. "Everyone will write async code" simply didn't happen in practice.
> Async infrastructure allows your stuff to be sync or async. While sync infrastructure forces your stuff to be sync.
Is that specific to the threading model for Python?
The reverse is true in nodejs where once you’ve got one async call, the entire chain must be async.
Python is the same as JS.
Async function (that returns something you need) can be called only from async function. That's why autor of this specific rendering framework/lib chose it to be async. So that the user functions called in components can be either sync or async.
Thanks for this answer. Async support is handy if the framework in which you're using the tools is async (let's say FastAPI). See my answer to a similar question on reddit: https://www.reddit.com/r/Python/comments/1fvv11p/comment/lqb...