Am I the only one whose first reaction to this is "Oh, great, yet another manner in which my next application won't be cross-platform?"
My second reaction being: "Oh, well, I'll just make it a web app instead of a native app."
edit Rephrased the last sentence.
1st thing: The people here asking if they are going to deprecate BSD sockets. No way that is going to happen. We are talking about 30yo+ API deeply integrated in the kernel, unix and userspace. OpenGL/CL is a very very different case. It's always been a third party thing an doesnt have the same level of usage. Not even close.
2. Not everything is a webapp or http. You may absolutely need to use the raw network without any encapsulation. This posibility must simply not die. Its true that most people will not need to use this apis and will use a http webapp.
On the API itself. I think it is a really good idea to make a new generic tcp/udp library. With everything we use today included, and as a first class citizen from the first minute of the design. The particular API they present looks good and it is very well thought out. Mostly integrates async tcp/upd/tls seemless and supports changing interfaces on the fly. This alone is a big improvement. Does this while still providing raw access to the out/input net queues. You can even access the lowlevel details and parameters if you want or need to.
However this is not the first modern network API. QT (qt network) has a good network layer for one. There are simpler alternatives: libuv, libevent etc. This are more speciallized and dont handle all that Network.framework offers.
> 1st thing: The people here asking if they are going to deprecate BSD sockets. No way that is going to happen. We are talking about 30yo+ API deeply integrated in the kernel, unix and userspace. OpenGL/CL is a very very different case. It's always been a third party thing an doesnt have the same level of usage. Not even close.
I agree that removing sockets would break large chunks of the ecosystem. On the other hand, after OpenGL's removal, it's not clear to me that Apple cares anymore about anything outside of Cocoa.
> 2. Not everything is a webapp or http. You may absolutely need to use the raw network without any encapsulation. This posibility must simply not die. Its true that most people will not need to use this apis and will use a http webapp.
Of course. Nearly 100% of my code is not webapp/http. Which is why I'm annoyed when I see (or in this case, fear) cross-platform APIs disappear.
> On the API itself. I think it is a really good idea to make a new generic tcp/udp library. [...]
I have no problem with a new, better, API. But I would certainly be more enthusiastic if any effort was presented to make it cross-platform and, hopefully, open-source and/or standardized.
They opensourced libdispatch[1] and ported it to linux, so there's hope they might do the same with Network.framework. It would be time consuming, but it shouldn't be hard for someone in the opensource community to write a linux / BSD implementation of this stuff on top of posix sockets & libdispatch.
I suspect the reason they didn't opensource it is that it looks like it was designed mostly with phone apps in mind, not servers. And thats a shame - it looks like it would be a great addition to the swift server story, especially given it does user-space networking out of the box. I still prefer swift's ergonomics over rust for application development, and this would help immensely. (Rust is steadily closing that gap though, what with native wasm support and async/await on their way.)