[ramensea]

I work in Swift on iOS. I think the "Swift on a server" idea is way over hyped. There are so many issues with the whole Swift stack adopting that servers side would be a mistake IMO. One of issues with Swift on a server is ARC vs a Go-like GC. If a company is legitimately concerned about runtime efficiency, they already have such great solutions. Go being one of those.

[abalone]

I would love to hear your perspective but this is not a well supported argument. ARC is one of the most interesting things about Swift on the server. Historically one of the greatest challenges with servers is the impact of GC on the long tail of performance and latency. So, so much work has gone and continues to go into addressing the problem of low-overhead GC. You can appear to get great performance but then when you look at your stats you see that some significant percentage of your users are exceeding your maximum latency goals due to GC kicking in. Go and Java have made great strides but sometimes at the cost of memory inefficiency and/or optimizing for specific cases.

Reference counting, by contrast, is entirely predictable. It doesn't defer any work. I would argue that CTOs are a lot more interested in consistently low latency than in requests per second. So it's very interesting to see an approachable, performant language take the ARC route on the server. It is early days though.

[ramensea]

My main issue of Swift's implementation of ARC is it commonly leads to memory leaks. Even experienced developers can cause unintentional memory leaks. It's extremely common in iOS development. It's also hard to even detect and eliminate them, you just seem memory usage climb as your app ages. It not an issue with iOS because it is commonly very small and an app's have such a short lifecycle.

ARC would be just one my issues using Swift outside of iOS.

I think you are overstating the pause duration of a modern GC. I have used both Go and the JVM server side, not at a huge scale but enough to see GC effecting response times. They add some fluctuate, but nothing compared to network latency or the multitude of other factors that fluctuate heavily. It was never significantly relevant for response times. I'm looking at my server logs right now and theres not even a real correlation between GC and response time. Unless you are considering a 0-10ms fluctuation.

If you are interested in using an ARC server side I know Kotlin Native is using ARC however their implementation eliminates the cyclical reference issue.

[abalone]

Nah, I’d say Swift’s good support for value type semantics helps cut down on leak problems. Depends on the patterns you use of course but I can see that being a good approach for server apps.

Funny you say that because just this week there has been an investigation into what seemed to be “leaks” but turns out it’s memory fragmentation. It’s a fascinating read into how to debug a server problem if you’re into that sort of thing.[1]

Agree that modern tracing GC can be very good in a wide range of cases but there are some where it’s not. Very dependent on the case. Ultimately you are deferring work and hoping to find some time in the future to squeeze it in unnoticed. ARC is a cool paradigm to explore on the server as it doesn’t have this problem to begin with.

[1] https://forums.swift.org/t/memory-leaking-in-vapor-app/22209...

[ramensea]

Value types are great, but they don't help cut down on cyclical references as the type of coding that will cause memory leaks is done in objects. Typically objects with complex dependencies and inheritance hierarchies.

Memory fragmentation is another legit concern I guess, as far as I can remember iOS has no memory compaction. Again not a necessarily an issue for a short live user space application, it is a larger one than memory leaks at least at my company. In some hot spots of our app we specifically slow down reading of some queries to reduce memory fragmentation.

Frankly Chris Lattner's claim that a GC leads to 2x-3x memory consumption over ARC is unfounded and sorta shocking coming from someone held is such high esteem. It's something thats continually shown to be untrue.

It always seems Swift's biggest selling point is it uses ARC instead of a GC, which is either not a large issue or a GC is actually more beneficial. Other than that you still haven't dealt with the toxic "Swifty" community, the terrible tooling situation, the immature libraries and frameworks, etc, etc.

There seems to be so many better solutions to writing server side code. This is all coming from someone who uses the language on a daily basis.

[ramensea]

Glad to see Vapor/Perfect has toned down their "we are going to change the world by releasing a new web framework" rhetoric on their sites. When they both first did announced them it was pretty cringe

[fulafel]

Refcounting has long tail latency too arising from cascading deallocations.

(And then you have ref cycles which is another kind of headache. And poor cache behavior from all those refcount updates.)