Hacker News Reader

Comment by saagarjha | Hacker News Reader

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.

View on HN

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.

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.

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”.

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

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.

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

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.

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?

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.

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.

Reply on news.ycombinator.com