It may be worth mentioning – perhaps in the FAQ section of the vision document – whether there is any relationship between this and other networking technologies, such as distributed actors or sockets, or NSStream, etc, and to what extent. Even if these topics are ultimately out of scope, it would still be helpful to acknowledge them and clarify that explicitly.
1 Like
Isn’t Swift Concurrency still embarrassingly slow compared to careful usage of DispatchQueues and EventLoops? It still lacks important fundamentals, like resuming continuations in-place (donating the caller’s thread).
Furthermore, it’s hard to imagine how Network.framework and SwiftNIO could “converge” any more than sharing the same high-level API. Please don’t worsen Network.framework just to satisfy this Swift vision.
Also, as someone who implements many complex network protocols, I find event-based multitasking a better fit than thread-based multitasking. Handlers and callbacks are complex (due to the implicit multitasking they create), but they let me express the operations of network protocols directly and achieve the best performance. High level interfaces should of course be thread-based (i.e. async functions), but I don’t think Swift Concurrency belongs any lower in a network stack.
I think a huge open will be completing the story around ~Copyable and lifetimes, as well as substantial ergonomic improvements in these areas. These technologies are vital tools for efficient implementation, but frequently impose challenges today.
Agreed, this is a good suggestion for addition. Will tackle this in an update soon.
To the extent that this is true, it’s going to be a critical part of making this story successful. We should be unafraid to drive language improvements where we need them.
We have no intention of worsening anything! I should stress as well that this vision relies on the enthusiastic engagement of the NIO and Network.framework teams, as well as various other stakeholders. Neither of those teams is going to be forced to do anything they think is a bad idea, or which will produce a worse outcome than what they already have.
Networking frameworks are business critical, for everyone who uses them. Entire app economies run on Network.framework and URLSession, and entire backend services run on NIO, and Apple of course runs on both. Making either of these worse is a very bad idea.
I do think there is some room for middle ground though. A good example would be protocol implementation sharing. Currently, a NIO ChannelHandler and a Network.framework Framer are very similar in concept, but totally incompatible. That limits re-use of protocol implementations, which causes many people to need to “pick a side” when they could produce something more generally useful. It also causes the NIO and Network.framework teams to do duplicative work: we both have a WebSocket implementation, for example. This is likely a very fruitful area of convergence, and as a side benefit it would enable more innovation in the networking space by allowing other ideas to use a shared protocol composition API more easily.
9 Likes
I agree with Cory that the story around ~Copyable and lifetimes needs to be completed. In addition to this, I personally think we need to invest more into Concurrency features such as new streaming protocols for reading and writing that leverage spans, integration of async I/O into executors and more. We can see that both the NIO and Network.framework APIs that bridge their respective scheduling mechanisms into Concurrency are quite performance prohibitive due to the usage of continuations and the inversion of control.
2 Likes
This is great news!
It would be great to see on the currency types URLEncodedBase64 and EncodedBase64. As far as I know, this type is implemented in many places in the server ecosystem: Foundation, in swift-nio (based on swift-base64-kit), jwt-kit and in swift-webauthn. Ideally, there would be an unified implementation like described on the vision for the other currency types.
4 Likes