3 ms·

> I think the main thrust is function color is infectious My response to this would be that this infectiousness is not a feature of async/await but an intrinsi

> I think the main thrust is function color is infectious 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. Another part of my response would be that it doesn't need to infect your entire code base, and that it actually pushes you in the direction of keeping your business logic (which can be sync) separated from your infra logic (which is almost guaranteed to be async). This too I see as a good thing, mixing business logic with infra logic tends to push you in the direction of death by a thousand cuts bad performance. You can achieve this separation as follows: async def your_endpoint(): business_object = await db.get() business_object.do_business() await db.save(business_object) The blog post I linked to goes into more detail.

Calavar 2y ago
> 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.
- wesselbindt 2y ago
  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.

Calavar 2y ago

> 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.

wesselbindt 2y ago
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.