particular (and thus, Networking TS since they have identical
interfaces) is "difficult to use."

>

> I believe it is wrong to blame Asio for this.

I disagree. Recently, I've been coding parallel, including networked & asynchronous, programs in C# and Java, and the experience has been a JOY. You get threads, executors, synchronization primitives, tasks, cancellation, monadic futures and concurrent (blocking and non-blocking) data structures out of the box with the platform, plus a myriad of extensions as libraries. As for executors, you don't need to be bothered with them unless you really want to for some reason.

In the beginning the C# program had 2 bugs (premature exit and deadlock) both of which were easy to find fix. This program has now hundreds of hours of heavy usage w/o bugs. It was easy and a joy to build thanks to the platform facilities.

In the java program I'm developing now, UI must be updated from "the UI thread". It took me whole *half an hour* to figure out how to write an executor that delegates execution to the UI thread and how to continue a completed future there (the flow is asynchronous network thread -> ui thread). All that just using the official JDK documentation, no external tutorials needed.

On another C++ project, I had to roll my own.. basically everything built upon thread/mutex/cv and _unfortunately_ I decided to use asio for networking and serial ports. I feel dread every time I have to visit asio code and I regret I simply didn't use native Win32 APIs with direct callbacks. There are still native bits in there because Win32 natively supports cancellation of _synchronous_ blocking operations.

Once I attempted to write an asio service, tried to understand the simple example from the documentation, and I gave up. I used a thread, blocking call and CancelSynchronousIO (and I consider myself fortunate to develop for Windows only that has it).

Asio _is_ a relatively nice wrapper around socket and serial port APIs, but that's about it, IMO. On the other hand, I could have written the same wrappers around native APIs in two days and not haul along what I consider the baggage of technical debt that is asio in the codebase.

So now I'm regrettably stuck with asio for the forseeable future for two reasons: 1) laziness (i.e., writing the said socket/serial wrappers) and 2) need for timeouts and cancellation (just as well served by thread per client and CancelSynchronousIO). Lesson learned the hard way 😞

Conclusion, if any: many people just want/need thread per client and synchronous IO for simplicity, but until asio/networking TS provide for timeouts and cancellation of synchronous requests, it's a wrong tool for those people, me included.