swift 5.5 supports concurrency, is there any change in swift-nio?
Are there any changes to Future and Promise? May be deprecated?
This has been covered in Future of Swift-NIO in light of Concurrency Roadmap.
The short version is that the core of SwiftNIO does not change, because we cannot meet our performance guarantees under the concurrency proposal as it stands today. We have a _NIOConcurrency module available that adds a number of entry points for concurrency support. This allows interop between NIO and concurrency programs.
In general we expect the high-level NIO wrappers such as async-http-client and grpc-swift to adopt concurrency wholesale, and essentially to remove EventLoopFuture from their APIs. Most users should not need to interact with NIO directly, and so those users should be able to essentially forget that it exists.
In the fullness of time, as concurrency matures, we'll re-evaluate. In particular, custom executors would be an opportunity to investigate more substantial adoption of concurrency. With that said, NIO is at its core almost entirely synchronous, and needs to be able to park its event loop threads in selectors. This is not something concurrency supports today, so the fundamental low levels of NIO will not change until that changes.
11 Likes
swift does not have garbage collection. After 5.5 adds concurrency, can it be comparable to golang's gin?
Comparable in what way?
I just need some data to convince my colleagues.
Well for what it's worth, SwiftNIO is not directly compatible to gin. gin is a web framework, while SwiftNIO is a networking toolkit. SwiftNIO is much more like golang's net than it is like gin. Vapor would be a better comparison point for gin.
2 Likes
Hi folks,
we're working on a guide of useful information wrt. server side libraries and NIO, you may want to track it: Swift Concurrency adoption guidelines for Swift Server Libraries #70.
4 Likes