> My response to this would be that this infectiousness is not a feature of async/await but an intrinsic property of the function. A function calling an expensive function is itself expensive. This is not a bug, it's just reality, and async forces you to be upfront with that.
You're right, the async keyword describes a reality about a function, and any attempt to syntax sugar your way out of that reality will leave you with a leaky abstraction. Async is async whether you have colored functions or colorless functions.
On the other hand, should changing a single function from synchronous to async require you to touch up your code in 30 different places across 10 different files? If you know what you're doing and you're okay with the async call, why do you have redeclare your intentions over and over again like you're punching in nuclear launch codes?
It's an opinionated question. You can see a similar design tradeoff in Zig's approach to generics (implicit type constraints) versus Rust's approach to generics (explicit type constraints) Rust's explicitness removes potential footguns, but it's also an absolute PITA to refactor your type system when you have to.
I do understand that the point the blog is making is the infectiousness. My point is when you drop the meaninglessness of blue/red and replace it with the more meaningful async/sync, this infectiousness goes from being arbitrary and annoying to completely natural, and even desirable. If all of a sudden you find yourself wanting to make some function async on top of a stack of 10 sync function calls, you're probably doing something ill-advised[1], and async/await making this difficult is valuable feedback on your design. Is this feedback useful in every system? No, just like static typing would be overkill for a five line shell script. But writing a paradigm off just because it makes it more difficult to set off certain footguns is, in my view, a mistake, and that's what irks me about this blog post.
[1] keeping business logic separate from infra logic is typically a good idea, see hexagonal architecture, or imperative shell functional core. Async/await is a convenient mechanism to guarantee maintaining this architectural choice, even for developers less familiar with this architecture.
You're right, the async keyword describes a reality about a function, and any attempt to syntax sugar your way out of that reality will leave you with a leaky abstraction. Async is async whether you have colored functions or colorless functions.
On the other hand, should changing a single function from synchronous to async require you to touch up your code in 30 different places across 10 different files? If you know what you're doing and you're okay with the async call, why do you have redeclare your intentions over and over again like you're punching in nuclear launch codes?
It's an opinionated question. You can see a similar design tradeoff in Zig's approach to generics (implicit type constraints) versus Rust's approach to generics (explicit type constraints) Rust's explicitness removes potential footguns, but it's also an absolute PITA to refactor your type system when you have to.