How is it leaky if the default paradigm of any sequential program is the expectation that it will block? If i write blocking socket code I know my thread is blocked until read() returns.

If i am writing async socket code I know to wait for poll or whatever it is that is the correct way to wait nowadays. My design would reflect that. The blocking is just moved to another thread effectively and this abstraction is packaged as a Future.

Asynchronous code does not require the rest of your code to be asynchronous. I can’t say the same for blocking code.

Well this is just stating a tautology isn't it?

Edit:

It would be a Hurculean effort, and I don’t think it’s a sustainable approach. If you’re writing a higher level library, it would be a lot to ask to check if your dependency’s dependency’s dependency maybe reads from a socket.

I guess I understand what's the argument here.

The author wants a safeguard against libraries that are blocking with compiler checks. I agree it is a nice thing to have. But they could have mentioned that without saying "blocking code is leaky abstraction".

[–] BB_C 4 points 1 week ago

Maybe this is a reductionist simplification of it, but his point is basically that, at least in the context of rust, async code is explicit and easy to introduce in a blocking context by simply blocking on it, while blocking code is not explicit about how blocky it is (and it's not a binary), and thus, it's not trivial to know where explicit unblocks are needed in an async context.

Blocking on async code is usually done with some_executor::block_on(), of which some very lightweight implementations exist, combined with the possibility of not requiring that the data's ownership be moved to the executor, nor is the data required to be Sendable to other threads (an executor doesn't have to be a multi-threaded work-stealing one).

Meanwhile, unblocking is done usually via blocking::unblock() or some_executor::spawn_blocking(), and doesn't offer such flexibility.