Why do server side projects seem to reinvent everything?

It seems like a lot of server side projects are not using Foundation or lib dispatch? For instance, SwiftNIO uses MultiThreadedEventLoopGroup instead of a dispatch source, and ByteBuffer instead of Data. I’ve seen similar patterns in almost every server side project. Why not use the shared types? If Foundation and lib dispatch have shortcomings o Linux why isn’t effort being put into fixing that for all projects? Won’t having a bunch of different types doing the same thing cause interopability issues. For instance if one library returns one data type and another takes a different one, won’t that cause unnecessary copies?

5 Likes

I read somewhere Swift-NIO didn't use Foundation because it delivers different behavior on Darwin and Linux. Furthermore Foundation is and Objective-C library in Darwin platforms.

2 Likes

This is actually a pretty common issue in a lot of Swift frameworks that are built with Linux support in mind.

Since so many Foundation methods/classes are just NSUnimplemented on Linux or have entirely different behaviors than their Darwin counterparts it's usually better, more efficient, or just easier to write a new type/class/whatever than deal with all the compiler flags to make a framework function on both macOS and Linux.

Most of Apple's time still goes into supporting its own OS's and relatively little time is given to porting code to the Linux Foundation framework.

Since many of the server-side projects rely primarily on Linux support, the best way to ensure that is to do it yourself. Most of these server-side project libraries are just swift wrappers built around the C APIs that have been battle-tested and are generally much more performant as well.

Also, since these C APIs are included on most, if not all, *nix OS's, they are "technically" cross platform and should function on any Linux OS and even macOS. Which is a lot more than Foundation can say since it's built on top of Objective-C and can't be easily ported to a Linux OS.

3 Likes

Ah well exactly what I feared with the opening to Linux... 8(

GNU/OpenStep could receive more love yeah...

1 Like

It seems clear by now that Foundation will never be as useful or popular on Linux as Apple may have initially hoped. I think the previous proposals for native Swift Foundation replacements should be revisited. I mean, Apple will move to all Swift native eventually, so it may as well start sooner rather than later and in the open as well.

13 Likes

From my experience it's the single biggest problem of the Linux environment: the people don't get and want standards. I just don't get why.

Au contraire - there a many people who want standards for Linux; just not the standard of someone else ;-)
Most likely, it's similar for every large project without a single authority, and Swift is no exception:
Many ideas on Evolution never turn into proposals just because there are so many people involved who often push and pull into opposite directions... if I learned anything here, than it is how extrem diverse the developer community is. Something you consider brilliant may seem like a terrible fault to someone else, and vice versa.
I bet if Swift wasn't started by an extremely small group, we would still be discussing if "let" is better than "const", and wether inheritance should be possible or banned.

8 Likes

Tangent: I always thought that Data is a very unfortunate name for a ...ByteBuffer (or ByteArray)

2 Likes

The problem is Dispatch is just not performant enough for use on the server. I've tried to implement a simple socket server using Dispatch sources many times and it never compares to the performance of using epoll/kqueue manually. Dispatch was written with client applications in mind and that is a very hard thing to undo.

As for Foundation, the Linux implementation is getting better and better each release. I'm starting to rely on it quite a bit on Linux now. However, there are again a lot of APIs there that are overly client-centric. Foundation and Dispatch eventually need to be updated to something that is built with client and server applications in mind and will be suitable for use on iOS, macOS, Linux, Windows, Android, etc.

Regarding ByteBuffer specifically, that is an absolutely amazing type. I use it everywhere. Foundation doesn't have any data types like it. Using Data would be far too slow and does not give enough control over how the data is accessed.

1 Like

GCD slow? Is that a „feature“ of the Linux port?

I didn't say it was slow haha. It's just not as fast as doing epoll/kqueue manually. Which makes sense seeing as how it's a very large, complicated abstraction over threading that was primarily built for use on the client. Developers writing apps for macOS and iOS don't really need to worry about the overhead of a thread-context switch or the cost of synchronizing access to a variable--they have the entire device to themselves. Dispatch just doesn't seem like it was designed with server use-case in mind.

I tested multiple variations of socket servers built on dispatch source on both macOS and Ubuntu extensively. macOS was usually a bit faster, but nothing to write home about. Still cannot compare to the other options available. Swift NIO would not have done it this way if it were not necessary.

Swift NIO was designed after Netty, which is one of the fastest and most widely used IO layers in the world.

See this benchmark where it is able to respond to 2,447,315 requests in one second which places it #12 out of 270 other implementations.

2 Likes

Hmm what bandwidth are you trying to saturate? Even the, according to your benchmark very slow, Apache can easily saturate 10gbit networks...

I may understanding a requirement wrong but for me it sounds like a very theoretical speed up.

1 Like

Trying to stick to topic here, I’m genuinely curious: There has been some mention that ByteBuffer is more useful or performant than Data. Why? Data is just a struct wrapping a buffer too. Maybe there is an evolution proposal to be made here?

Indeed. If it’s truly a performance issue, what’s keeping us from porting the implementation to Foundation?

Indeed. Here’s the status of Foundation on Linux. It has a long ways to go still.

(btw: Hi dude, I’m felix91gr! How’s life? :))


Regarding Dispatch threads and Linux:

  1. Afaik, in Linux the Foundation port uses POSIX threads. I don’t know if there are plans for making the implementation more efficient or if we’re waiting on the swift-evolution discussion of the Swift threading abstraction itself.

  2. The Server Frameworks need something fast. My guess is that Dispatch might never be as fast as the available alternatives. And I also think that whenever threading is incorporated into the language, that will be the fastest alternative. Therefore, uses of Dispatch in a server-side context might not be long for this world.

It doesn’t seem like anyone here has actually read ByteBuffer’s source code. ByteBuffer serves a different purpose than Foundation’s Data and it wouldn’t make sense to try and merge them into a single type.

The topic of this thread is that there are many different implementations in the wild of these types. I could read a random implementation’s source, but that tells me nothing necessarily of the specific implementation you’re using, nor of the reason you’re using it.

Also, the question isn’t whether they should be combined. I’m more interested in which use-case is necessitating a separate type and whether it’s worth proposing ByteBuffer for Foundation