3 ms·
this is a controversial topic - right up there with static vs dynamic typing. I found your post helpful and well written, but in the end I still find myself su
by spinningslate 2y ago
this is a controversial topic - right up there with static vs dynamic typing.
I found your post helpful and well written, but in the end I still find myself supporting Bob's blue/red delineation as a helpful articulation of the key limitations with async/await. Why?
Because the only thing that the async keyword objectively says is "someone, somewhere down the call stack, decided to make their function async". You mention I/O in your post and it might indeed be because of that. You also mention cheap vs expensive and, again, it could be that. But those are heuristics: not objective or definitive. The cheap vs expensive point is particularly problematic (a) because there's no delineation between the two, and (b) because it's different for different use cases.
Is reading a file expensive? It might be. If I need to read a 1GB file just to pick out 10 characters, then the read is expensive. But if I'm reading that same file to run a stochastic simulation, then the time to read the file might well be insignificant in comparison to the computation. And, besides, I can't run the computation until I've read the input data anyway - so it's not helpful to me that someone else decided that reading files is "expensive".
The other argument I've seen for marking IO as async is partial failure: IO can fail in ways that local computation doesn't (modulo hardware failures - which can occur, though are much less common). That would be legitimate - except, per above, "async" doesn't definitely mean "does I/O". It only means someone, somewhere in the chain, decided to make their function async. And now I'm constrained to make my functions async too because of its transitive nature.
I'm not against cooperative multi-tasking per se. I do prefer the developer experience of runtime-supported fine threading such as Erlang processes or goroutines. That's a preference though, and others will feel differently - ref comment on static vs dynamic typing.
- jayd16 2y ago> It only means someone, somewhere in the chain, decided to make their function async Well it specifically means that a function can yield its execution context. That property is taken on when one function calls an async function. It has clear implications for very common threading patterns, I think it's right to argue that using blue/red obfuscates that.
- shadowgovt 2y agoOne utility of blue/red is that it applies to other contexts that would cause similar "poison" effects as well. Some type systems allow for validated vs. unvalidated data. And then all of a sudden you have a creeping concern that half your functions talk about char* and half your functions talk about String (or, perhaps, a heterogeneous collection of strings: userid and telephone number and the like). Suddenly the code on the outside of the validation boundary can't use the code on the inside without addressing the question of whether their data is valid.