Hacker News Reader

Comment by tyingq | Hacker News Reader

Is "server side Swift" becoming less niche? I'm not clear on why it isn't competing more with Go and Rust.

My impression has been that Swift is still very much seen as an “Apple” language, rather than a cross platform one. Another issue is that there are some operations that lead to crashes if they detect illegal behavior, in the name of providing safety and consistency. Some feel that this kind of behavior is counterproductive in a server environment because it would lead to the server keeling over if something goes wrong.

Tooling outside of Mac I imagine is lacking as well. I also asume libraries outside of Mac too? Strong standard libraries make languages easier to adopt. Go had a web server out of the box removing the whole "which web library do I use?" element out of the equation.

Ahh, yes. That makes sense. No batteries included.

Swift on Linux has access to a substantial portion of Foundation as well as any other C libraries, such as libc.

There are a lot mismatches.

For example, I reported a bug about CFRunLoopMode, where the original C-based CF used a comparison of pointer address to determine the equality of two run mode names. The original C version actually compared using the identity rather than equality as the commonModes was defined as a static CFStringRef (CONST_STRING_DECL(kCFRunLoopCommonModes, "kCFRunLoopCommonModes")). Of course this is an optimization for speed on Mac but this is, unfortunately, not supported in Swift and its replication of CF, because in Swift it has to be a public static String. As for today you cannot use commonModes in Linux.

Unfortunately Apple still considers (Core)Foundation to be outside the auspices of Swift Evolution, which makes getting issues like these fixed much harder.

Yeah, but a good chunk of it throws Not Implemented exceptions at runtime too.

That’s why I qualified my statement with “substantial portion”.

Swift outside of Xcode hasn't been the best of experiences even on macOS. Swift Package Manager works well from the CLI(although the Rust compiler's error messages have spoiled me), but using other editors usually requires some sort of sacrifice. A lot of them have inconsistent code completion if any at all, or no debugging or inline error messages. It's not bad for working with small Swift scripts, but working on a bigger project without those tools isn't great.

> Swift outside of Xcode hasn't been the best of experiences even on macOS.

Even _in_ Xcode it's quite horrible. Only supporting the one major version of Swift bundled with Xcode and forcing old projects to upgrade? Horrible.

Xcode 9 supports two major versions and it seems likely that that will continue.

Interesting. I'm surprised not have seen more user contributed libraries for server side Swift that work around this, and the (mentioned below) lack of libraries, like ready made web server implementations. I viewed the apple fan club as more ambitious in the past. To be fair, I have zero experience in the Mac/iPhone area.

I had assumed zealous iPhone devs would want a homogenous environment where the client and server used the same rough codebase and libraries. Kind of like the node.js crowd, which I'm equally inexperienced with.

There are many. There’s even an “official” one, SwiftNIO, that was released recently.

Ahh, okay. Fairly niche, I assume? I'm pretty religious about following HN and other tech news feeds, but have never heard of "Swift NIO". While, on the other hand, I've heard tons about node.js and Golang developments, even though I'm equally inexperienced with those.

Feels like Swift afficiciandos aren't quite as good at PR as their base competition.

I'm basically still back in the jQuery, Python/Django, Ruby/Rails, Tomcat/Java/Spring, PHP/Laravel, space. I understand the comparisons and tradeoffs with those. So, perhaps, I'm fairly agnostic about what's "hot" and "popular".

> Fairly niche, I assume?

I really have no idea, since I haven’t used it. It is very new though.

> Feels like Swift afficiciandos aren't quite as good at PR as their base competition.

I guess the issue here is that very few people have even heard of using Swift for server-side development.

Apple working on an HTTP server library called swift-nio-http2 [1] that they say is "coming soon", so I would wait for that before using swift on the server side.

[1] https://github.com/apple/swift-nio

Please forgive me for my rant:

Building Swift from source is a big pain in the *. I tried to build it on a shabby VPS running CentOS 7, which is not of my choice but because it was discounted. I had to setup 6GB of swap file to avoid OOM, and then found the intermediate files filled up the disk. Why does LLVM needs so much space to build?

I actually had to build LLVM last week, so I feel your pain. I ran it on my Mac, thankfully, but I accidentally built in debug mode and ended up a 25 GB build folder. Turning on release mode and -Os brought it down to two or three gigabytes.

After installing Xcode and stuff, on my MacBook Pro, there is usually less than 10GB free space. I have to delete and purge up and down till ~14GB for sure every time Xcode gets updated.

If you’re looking to clean some space, I recommend checking out ~/Library/Developer/Xcode. Among other things, Xcode stores device symbols for every iOS device you’ve ever connected to your Mac here. You might be able to clean out a couple gigabytes.

In my experience building LLVM (not for Swift though), it depends on your make -j switch. With -j 16 I would run out of memory quickly (32 GB RAM, 16 GB swap), with -j 1 it would be quite conservative memory-wise, but take hours to build.

So I switched to ninja (cmake -G Ninja). It can use all the cores and not run out of memory.

It is not really portable outside Apple eco-system, just like Objective-C ever was.

The set of libraries and supported OSes is a tiny dot comparable with the Go and Rust.

And they aren't even the most relevant for enterprise servers, Java, .NET, C++ are.

If we start listing the kind of libraries used in distributed applications, database backends, Swift has hardly none of them.

IBM is the only major company playing with Swift on the server and it remains to be seen for how long.

I think server side Kotlin will steal all the thunder from Swift. It's very similar in style, but JVM stack makes it more versatile, IntelliJ tooling is leaps ahead, and the language seems to a bit more smarter designed overall.

I’m with you on the prediction, but I disagree with your last point. My impression of Kotlin (as an avid swift user) is it is a modern, well-designed Java, but it’s still Java. What Swift does differently is what really sells me on it in the first place: copy on write and deterministic (for the most part) ARC.

ARC an be a real pain with closures though. I'm often discouraged to use them in Swift, because I can't be bothered to figure out if I have all my references correctly set. GC lets you not worry about it. It comes with its own disadvantages, but does it really matter in most cases? Optimizing for productivity seems way more important then pure performance these days.

Well, the gotcha's are pretty straight forward - don't capture self. Xcode actually features runtime memory leak detection which can detect this (though I've never seen it actually work...).

My personnal reason for not moving to swift is concurrency. As long as there isn't a clear prefered model for concurrency (node-style event loop with asyncs or actors), i won't start developing on the server with this language (which is great).

Unfortunately i don't see a lot of progress being made on that front since Chris lattner wrote its concurrency manifesto.

If you follow the trend - the language never becomes really popular (generally) unless the most popular platform (even among developers) - Windows - is fully supported. Go never really took off until this happened.

Aka crossing the chasm.

Swift on Linux, which is the key to "server side" swift, is really coming along. However, it still has several rough edges that, while they can be worked around, mar the experience and probably discourage a lot of casual tinkerers who try it.

For instance, if you download the Swift 4.1 tarball, uncompress it, and start up the REPL, it doesn't really work. The first thing you will do is probably "import Foundation" (because the Swift standard library is really minimal, so Foundation is where most of the interesting stuff is). Then the REPL will complain:

    error: repl.swift:1:8: error: missing required module 'CoreFoundation'

You'd have to hunt on the Swift bug tracker[1] to figure out that's a packaging problem on Linux, and to fix it you have to do something like:

    sudo chmod a+r /opt/swift/usr/lib/swift/CoreFoundation/*

Then, say you make a toy program, and try to debug it using lldb. That might seem to work, but as soon as you stop at a breakpoint and try to print a value, booom! lldb will spit a wall of error text at you. (This assumes your program imports Foundation, again, but almost every program will.) This is also work-aroundable, as long as you are able to find the JIRA ticket thread describing how to work around it[2].

There are a bunch of little issues like this, that make it clear that Linux isn't yet a first-class platform for Swift. All this stuff is gonna work fine on your Mac.

OTOH though, the Foundation library itself has made amazing, amazing progress. It's super useful, mostly finished[3], and its pretty clear when stuff that works on Apple platforms isn't yet ready on Linux (because those bits use NSUnimplemented() which just crashes the program). That's important because without Foundation, which contains a lot of the basic building blocks for programs, Swift won't be competing with Go or Rust.

Swift Package Manager is also fully cross-platform and awesome.

Apple also recently released an interesting low-level cross-platform asynchronous event-driven network application framework, called swift-nio[4]. This is super-interesting, but also causes more churn; for instance, once swift-nio was released, the team behind the most popular Swift web application framework, Vapor[5], started frantically rewriting their v3 release to leverage it.

So... yeah, I would say "server side Swift" is becoming less niche, but... it's still pretty niche. On Linux, it's far less mature than Go or Rust, and you need to expect to have to bing[6] a bunch of annoying little issues to get things working.

[1]: https://bugs.swift.org/browse/SR-2783

[2]: https://bugs.swift.org/browse/SR-7065

[3]: https://github.com/apple/swift-corelibs-foundation/blob/mast...

[4]: https://github.com/apple/swift-nio

[5]: https://vapor.codes

[6]: just joking! haha ;-D

Wow, super detailed. I never get anything this detailed or informative on any other type of forum. Appreciate it.

I'm not yet sure if "server-side Rust" is actually viable. Some of the language concepts are too complicated, and the obvious benefits (no need for GC and better control for concurrency) don't seem to apply to many server-side things.

Server-side Swift doesn't suffer from these problems, IMHO, but admittedly its Linux support is still a bit questionable, whereas Rust's Linux support is obviously superb. Swift on Linux probably works the best if you're able to use the officially supported LTS distribution, which currently is Ubuntu 16.04.

There is no good reason to move away from Ruby on Rails, Django, Node, etc.

I'd argue that now that Typescript is gaining momentum - I'd say there's a good case for Javascript (Node.js) solidifying itself as the leader for anything but apps that are performance critical.

Well, you are overlooking the language itself: how nice is it to code in, does it help you iterate more quickly, and how much does the awesome type system help you prevent errors, refactor code more easily, and promote stability over time?

These answers will vary wildly from person to person, but for a lot of people the answers to those questions will definitely provide a "good reason to move away from Ruby on Rails, Django, Node, etc."

I agree with you that the advent TypeScript is strengthening JavaScript's position immensely. TypeScript is really awesome. But it is still a type system bolted onto JavaScript, and it being a strict superset of JavaScript — even though that was a great design decision on balance — means it just can't do as much for the programmer as Swift can in that regard.

But if you wanted a comprehensive type system then why not Scala.

You get similar syntax to Swift whilst leveraging the best server side libraries available on any platform.

I learned enough Swift to know that I think it’s terrible and that I really don’t like the way that Apple designs anything. They couldn’t get strings right the first time because they were too pedantic about how I should think about them, they prefer all sorts of weird shortcuts that make code unreadable, like trailing closures, if-let and some other things I can’t remember and the tooling is clunky, slow and generally sub-par to my preference. I think Xcode and Mac OS are the worst and I’d probably kill myself if I had to actually code with them instead of just using them to compile stuff like I do now with my React Native projects.

I’d rather use just about anything else. If I could use C# everywhere, I would because Microsoft really knows how to cater to developers like no other company and their tools are second to none in many cases.

on the other hand , if let and guard let , together with optional, is what makes swift the safest language i've ever developped with relative to null pointers exception (I haven't had any in years) yet bringing almost no syntax overhead.

Compare that to go ( which still has npe) or rust ( whose borrow system appears to be a real pain point) and i think it has an edge.

Have you tried crystal? It has much of the same in how its union types work.

Performance-wise server-side Swift is miles ahead of Node and Django. Apart from that, the tooling is indeed terrible...

Apple to me is not a software / services company. They failed to make Swift popular and imho it will just artificially keep Swift alive while everyone else will be using RN,Xamarin and similar.

Swift is popular on their platforms, just like .NET used to be popular only on Windows, or even Java used to run better on Solaris back in the day.

OS companies care about their own developers, getting their own languages used outside of their eco-systems, only when it matters to their bottom line.

Reply on news.ycombinator.com