We can agree that linearly laid out blocking code is simpler to write and debug than async code with callbacks. Ideally, one shouldn't even have to annotate fun

We can agree that linearly laid out blocking code is simpler to write and debug than async code with callbacks. Ideally, one shouldn't even have to annotate functions as async. If an API call blocks, let it block. That would simplify a lot of conditional workflows immensely. The trouble is that threads are heavyweight, particularly in context switching. So the user has to work around it by explicitly creating async functions, task schedulers, futures and so on, to avoid having to block a crucial thread (as in GUIs or network event loops). Languages like go and erlang help you avoid that by having the entire ecosystem (libraries included) give you permission to write blocking code, and that under the hood, they would take care of fast context switching and async I/O. That is what loom hopes to do. Ideally in this world, the ordinary developer would not have to use nio at all ... simple blocking APIs should suffice.