Future in Combine (that is, without using the rest of available
Publisher operators) probably wouldn't give enough benefits as compared to
EventLoopFuture that you probably already use when interacting with Soto.
If it's a SwiftUI app, or if you use TCA, then converting from
EventLoopFuture to Combine's
Future could occasionally be beneficial, but I don't know if there's a recommended way to do it properly. I think it wouldn't be too hard to implement though. You just need to be aware that
EventLoopFuture is always tied to an event loop, while with Combine's
Future you need to maintain subscriptions for it to work.
The benefit of having that conversion working would be that there's much more in Combine (and OpenCombine if you're interested in supporting other platforms) than a plain
We could say that comparing Combine's
Future to NIO's
EventLoopFuture is an apple-to-apple comparison, but Combine vs NIO would be an apple-to-oranges comparison then. Both of these frameworks give you much more than cutting down on nested closures, and it depends on what other libraries you use in the app (like Soto, SwiftUI, TCA etc) and what's the overall architecture.