> Sure, the same can be said of an async library
An generic future is much harder to be called like this. You need to to create wakers and if you don't properly handle them you'll busy loop. You also need to provide the exact runtime the future needs for its I/O.
> so long as you're okay with none of your other flows being able to make progress in the meantime
And isn't that what blocking code does all the time?
> ‘The best of both worlds’ means that it shares the advantages of both
If you look at it from the perspective of a caller:
- you can easily use it from blocking code without needing a runtime
- you can easily use it from async code without blocking the executor
As such it does provide the best of both worlds to the caller.
It is true that it's the worst of both worlds for who is writing the Sans-IO library though.
> or, as we used to call it, pure functional programming
You can for sure describe this as "pure" and "functional", but I bet most people think of a different paradigm when talking about pure functional programming.
An generic future is much harder to be called like this. You need to to create wakers and if you don't properly handle them you'll busy loop. You also need to provide the exact runtime the future needs for its I/O.
> so long as you're okay with none of your other flows being able to make progress in the meantime
And isn't that what blocking code does all the time?
> ‘The best of both worlds’ means that it shares the advantages of both
If you look at it from the perspective of a caller:
- you can easily use it from blocking code without needing a runtime - you can easily use it from async code without blocking the executor
As such it does provide the best of both worlds to the caller.
It is true that it's the worst of both worlds for who is writing the Sans-IO library though.
> or, as we used to call it, pure functional programming
You can for sure describe this as "pure" and "functional", but I bet most people think of a different paradigm when talking about pure functional programming.