The first part, yes, but the second part (the meat of the article) is more interesting and is making a claim of a better approach than just "write an interface"

The first part, yes, but the second part (the meat of the article) is more interesting and is making a claim of a better approach than just "write an interface": write an interface that returns some concrete set of values that you can work with instead of calling functions in some other interface. This reminds me a bit o the "sans IO" model for writing network protocol implementations: https://sans-io.readthedocs.io/ https://sans-io.readthedocs.io/ By having your HTTP protocol implementation accept a value input "These bytes were received" and return a value output "Please send these bytes" instead of directly calling read() and write() methods from an interface, you can write an asynchronous upper layer API using your favorite async stack as easily as a synchronous one - you're no longer baking in the idea that the library handles making the operations happen and therefore sometimes blocks in a read. (And the lower-level library is also testable without mocks, etc.)