I am working on converting some database bindings from Java to Swift from scratch. It is tempting to do this using Swift Concurrency and Actors to be dependency free, Swift 6 opens up a lot of possibilities to do this comprehensively, but given that almost all serverside bindings I've found rely on NIO at the moment, it raises a few questions in my head:
Is Swift Concurrency actually the best tool for the job? Just because it exists doesn't mean it makes sense in every use case. When it comes to serial execution, Swift Concurrency can be a bit of a pain given actor reentrancy.
Is it really worth the trade off of being completely not backwards compatible? For example, if RediStack were to move to Swift Concurrency wholesale, that would mean anyone implementing something in the future that wants to use it would have no option but to use Swift Concurrency. From what I've seen it is hard and unsafe to bridge sync code to Swift Concurrency.
TLDR: Another way to put this is, for new packages/bindings built for serverside Swift, what are the arguments against using pure Swift Concurrency and for continuing to depend on NIO and EventLoop indefinitely (while still offering async versions of functions, etc)?
The truth is somewhere between: NIO is very much here to stay and is the gold standard for networking on the server side.
At the same time, for “concurrency” swift concurrency is the way forward. And there’s a point at which you’ll have to bridge from one to the other.
The nio team have been hard at work providing more async APIs into making this more seamless, using async sequences and writers etc.
Today you likely still will have a bit of a mix in your library internals, and use some compat APIs between event futures and async, in general that’s how I’d look at it.
With task executors in swift 6 you can even run async code on the NIO event loops etc.
So the two worlds are converting but I don’t remember how complete the latest async sequence APIs are in NIO right now; I’m sure one of the team can fill that in shortly :-)
Hope this helps,
As far as use facing api: you should pretty much never surface event loop futures to end users nowadays I think. Make it all async methods and sequences.